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Preface 


The Guidance and Control Software Development Specification is document 
# 2 in a series of fifteen documents which fulfill the Radio Technical Commis- 
sion for Aeronautics RTCA/DO-178A guidelines, “Software Considerations 
in Airborne Systems and Equipment Certification [1]." The documents are 
numbered as specified in the DO-178A guidelines. The documents in the 
series are used to demonstrate compliance with the DO-178A guidelines 
by describing the application of the procedures and techniques used during 
the development of flight software. These documents were prepared un- 
der contract with NASA-Langley Research Center as a part of their long 
term research program addressing the fundamentals of the software failure 
process. 

This project consists of two complementary goals: first, to develop soft- 
ware for use by the Research Triangle Institute (RTI) in the software error 
studies research program sponsored by NASA-Langley Research Center [2]; 
second, to use and assess the RTCA/DO-178A guidelines for the Federal 
Aviation Administration (FAA). The two goals are complementary in that 
the use of the structured DO-178A guidelines in the development of the 
software will ensure that the test specimens of software have been devel- 
oped according to the industry standards for flight critical software. The 
error studies research analyses will then be conducted using high quality 
software specimens. 

The implementations will be subjected to two different software test- 
ing environments: verification of each implementation according to the 
RTCA/DO-178A guidelines and replicated random testing in a configura- 
tion which runs more than one test specimen at a time. The term imple- 
mentations refers to bodies of code written by different programmers, while 
a version is a piece of code at a particular state (i.e., version 2.0 is the result 
of code review). This research effort involves the gathering of product and 
process data from every phase of software development for later analysis. 
More information on the goals of the Guidance and Control Software (GCS) 
project are available in the GCS Plan for Software Aspects of Certification. 

The series consists of the following documents: 

- GCS Configuration Index Document no. I 

- GCS Development Specification Document no. 2 
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- GCS Design Descriptions One for each software implementation. Doc- 
ument no. 3 

- GCS Programmer's Manual Document no. 4, includes Software De- 
sign Standards, document no. 12. 

- GCS Configuration Management Plan Document no. 5A 

- Software Quality Assurance Plan for GCS Document no. 5B 

- GCS Source Listing One for each software implementation. Document 
no. 6 

- GCS Source Code One for each software i nplementation. Document 
no. 7 

- GCS Executable Object Code One for each software implementation. 
Not available on hardcopy. Document no. 8 

- GCS Support/ Development System Configuration Description Docu- 
ment no. 9 

- GCS Accomplishment Summary Document no. 10 

- Software Verification Plan for GCS Document no. 11 

- GCS Development Specification Review Description Document no. 
11A 

- GCS Simulator (GCS.SIM) System Description Document no. 13 

- GCS Simulator (GCSSIM) Certification Plan Document no. 13A 

- GCS Plan for Software Aspects of Certification Document no. 14 
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FOREWORD 


This specification defines the fourth problem to be studied as a part of a 
series of controlled case studies sponsored by NASA-Langley Research Cen- 
ter. These studies address the fundamentals of the software failure process. 
The goal is to develop a method for assessing, and engineering, reliable and 
safe software. 

This fourth problem, a guidance and control system for a planetary land- 
ing vehicle, represents an order of magnitude increase in problem complex- 
ity over the previous problems studied. It is specified using an extension 
to the popular method of structured analysis. This specification method 
was selected instead of a formal one for the sole purpose of not making the 
specification development activity a research effort in itself. In addition, the 
intent of the study is to observe failures, given that the software has been 
developed using a quality-oriented, state-of-the-art engineering approach. 

Note that this specification is written for an experienced programmer 
with two or more years of full-time industrial programming experience us- 
ing a scientific programming language. The programmer should have an 
adequate background, either through college courses or job training in math- 
ematics, physics, differential equations, and numerical integration. In addi- 
tion, an individual well-versed in aeronautical engineering should be avail- 
able to answer programming questions concerning vehicle dynamics. 

Much effort has been expended in making this specification as error free 
as possible. It has been validated by extensive peer review and informal 
walkthrough, coding a prototype implementation, and using an extended 
structured analysis design tool. 


Janet R. Dunham 


Edward Withers 


March 18, 1988 
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1. INTRODUCTION 
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PURPOSE OF THE GUIDANCE AND CONTROL 
SOFTWARE 


The purpose of the Guidance and Control Software (GCS) is to: 

1. provide guidance and engine control of the vehicle (shown in Fig- 
ure 1.1) during its terminal phase of descent onto a surface and 

2. communicate sensory information about the vehicle and its descent to 
some other receiving device. 

A typical terminal phase of descent trajectory is shown in Figure 1.2. 

The initialization of the GCS starts the sensing of vehicle altitude. When 
a pre-defined engine ignition altitude is sensed by the altimeter radar, the 
GCS begins guidance and control of the vehicle. The axial and roll en- 
gines are ignited; while the axial engines are warming up, the parachute 
remains connected to the vehicle. During this engine warm-up phase, the 
aerodynamics of the parachute dictate the trajectory followed by the ve- 
hicle. Vehicle attitude is maintained by firing the engines in a throttled- 
down condition. Once the main engines become hot, the parachute is re- 
leased and the GCS attempts to maintain the descent of the vehicle along 
a pre-determined velocity-altitude contour. The vehicle descends along this 
contour until a pre-defined engine shut off altitude is reached or touchdown 
is sensed. After all engines are shut off, the vehicle free-falls to the surface. 


VEHICLE CONFIGURATION 

The vehicle to be controlled is a guidance package containing sensors which 
obtain information about the vehicle state, a guidance and control computer, 
and actuators providing the thrust necessary for maintaining a safe descent. 
The vehicle has three accelerometers (one for each body axis), one doppler 
radar with four beams, one altimeter radar, two temperature sensors, three 
strapped-down gyroscopes, three opposed pairs of roll engines, three axial 
thrust engines, one parachute release actuator, and a touch down sensor. 
The vehicle has a hexagonal, box-like shape with three legs and a surface 
sensing rod protruding from its undersurface. 
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Figure 1.1: THE LANDING VEHICLE DURING DESCENT 




TERMINAL DESCENT 


Prior to t lie terminal descent phase, the vehicle falls with a parachute at- 
tached. This parachute is released seconds after the engines ignite and termi- 
nal descent begins. During terminal descent, the vehicle follows a modified 
gravity-turn guidance law until a pre-deterinined altitude is reached. The 
atmosphere introduces drag forces, including the random effects of wind. 
Differentially throttled engines slow' the vehicle down. These engines can 
control the vehicle’s orientation, and roll engines control the vehicle’s roll 
rate. Roll control is necessary to keep the doppler radars in lock and insure 
that the desired touch down attitude (land on two legs prior to the third ) 
is maintained. 

The velocity during descent follows the pre-determined velocity altitude 
contour. At approximately 60 feet above the planet surface, the vehicle is 
maintained at a constant descent velocity of ten feet per second. Once the 
surface is sensed, all engines are shut down and the vehicle free falls to the 
surface. 


VEHICLE DYNAMICS 

Frames of Reference 

Terminal descent is described in terms of two coordinate systems: 

1. the surface-oriented coordinate system, and 

2. the vehicle-oriented coordinate system. 

In the surface coordinate system, the z p axis is viewed as normal to the 
surface and points down as shown in Figure 1.2. The x v axis points north, 
and the y p points east. 

By defining a unit vector as a vector of length equal to one unit along 
each axis in both the planetary and vehicular frames of reference, a relation 
between these two frames of reference may be established. Any vector can 
then be defined as a multiple of the unit vector along each of the axes defined 
in the frame of reference. Thus, the velocity of the vehicle V may be defined 
in the vehicle’s frame of reference as: V Xy i v + V y V j v + V Zv k v , where i v , j v , and 
k v are the unit vectors in the x, y, and z directions of the vehicles coordinate 
system (unit vectors are usually represented by lower case i, j, or k with a 
hat to show that they are unit vectors). V Xv , V yv , and V Zv represent the 
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components of the vehicle velocity in the given direction. At the same time, 
the velocity of the vehicle may be described in the planetary coordinate 
system as: V Xp i p + V yp j v + V Zp k p , where the subscript p represents planetary 
rather than vehicle coordinates. Note, since the two coordinate systems are 
not oriented in the same direction, the values of V Xv will not be equal to V Xp , 
but the magnitude of the total vector V will be the same in both systems. 
Also the difference in the magnitudes of individual components represents 
the difference in relative orientation between the two coordinate systems. 

The dot product (a * 6 ) is defined as the magnitude of a multiplied by 
the magnitude of b and then by the cosine of the angle between the vectors, 

a ■ b = |a|| 6 | cos Lab 

The dot product is used to project a onto b and can be used to project a 
vector in one frame of reference onto another one. Rather than calculate 
the needed cosines each time a vector must be transformed from one frame 
of reference into another, the cosines of the angles between each unit vector 
of the vehicular and planetary coordinate systems are computed and placed 
into a direction cosine matrix. This matrix is then used along with the 
vector’s magnitude in each dimension of the original frame of reference to 
compute a dot product. This product gives the vector’s magnitude in each 
dimension of the new frame of reference. 

The transformation between the vehicle and the surface coordinate sys- 
tems at time t is specified by a matrix of direction cosines, 

f l\ h h \ l cosO(i v ,i p ) cos0(i v ,j p ) cos0(i v ,k p ) \ 

m\ m 2 m 3 = cosd(j v ,i p ) cos0(j v ,j p ) cos0(j v ,k p ) 

\ n i n 2 n 3 y t \ cosO{k v ,i p ) cos0(k v ,j p ) cos0(k vy k p ) ) t 

where 0(i,j) denotes the angle between vectors i and j, etc. 

The change in orientation of the vehicle during descent makes the update 
of the direction cosine matrix necessary at each time step. This update is 
specified in the following equation: 

( h h h \ o r u —q v \ / l x h h 

d/dt I mi m 2 m 3 = -r v 0 p v I I mi m 2 m 3 

\ n 2 n 3 J t q v -p v 0 / f \ «i n 2 n 3 

where the matrix containing the p v , q v , and r v terms is the rate of rotation 
about the axes of the vehicle which may be obtained from sensor values. 
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Linear Velocity 

The linear components of velocity for the vehicle during terminal descent 
are denoted by x v , y v , and z v in the vehicle coordinate system and by Xp, yp , 
and Zp in the surface coordinate system, where the dot () notation indicates 
derivatives with respect to time. 


Vehicle Position 


Vehicle position is expressed in terms of the surface coordinate system by 
transforming change in position (velocity) in the vehicle coordinate system 
into change in position in the surface frame and integrating as follows: 


and 




h 

rrt\ 

Til \ 

( *v 


h 

m 2 

”2 

! Vv 


h 

m 3 

U 3 )t 

^ Zv 


f x p ^ 

y P 

z p / 1 



dr 


t 


Angular Velocity 

Roll, pitch, and yaw angular velocities are represented by the quantities 
p v , q v , and r v in the vehicle frame of reference only. Roll is about the 
x v axis, pitch is about the y v axis, and yaw is about the z v axis, as shown 
in Figure 1.3. A more in-depth explanation of angular velocity naming 
conventions and other related material may be found in section II, part B 
of Reference [3]. 


Vehicle Attitude 

The vehicle attitude at time < is a function of the vehicle attitude (known 
by reference to celestial objects) at the start of descent at time to &nd the 
cumulative changes in attitude from time to to time t . 


Acceleration 

The linear components of acceleration for the vehicle in the vehicle frame of 
reference during terminal descent are denoted by x v , y v , and z v respectively. 
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Figure 1.3: ENGINEERING ILLUSTRATION OF VEHICLE 
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Further Reading 

The subjects of vector mathematics, transformations between frames of ref- 
erences, vector calculus, and rotating coordinate systems may not be suffi 
ciently covered here for the user; however, such depth is not intended for this 
document. Chapter 4 of Classical Mechanics [4] contains a detailed explana- 
tion of rigid body motion and transformation of vectors into multiple frames 
of reference or coordinate systems. Chapters 15 and 16 of Engineering Me- 
chanics [5] contains a more basic approach to the same ideas of multiple 
frames of reference and vector mechanics. Chapter 14 of [6] and Chapter 5 
of [7] also discuss rotational motion and multiple frames of reference, as well 
as vector mechanics and calculus. Two other books of possible interest are 
[8] and [9]. Both cover the mechanics of particles and dynamics, with strong 
references to particle trajectories and rocket dynamics. Also, these texts are 
basic in nature and require only a rudimentary knowledge of physics, math, 
or engineering. 

Notation 

Throughout this specification, matrix operations ( particularly multiplica- 
tion ), are required, and on some occasions, non-standard operations are 
used upon matrices. The following symbols are used to denote the types of 
multiplication to be applied. 

Dots (•) Small dots are used to denote scalar multiplication. For example: 

3 4= 12 

Multiplication sign x This symbol is used to denote standard matrix 
multiplication. This does NOT imply a cross product, nor strictly 
a dot product. The definition of this type of operation is given below: 

A x B = C 


where n 

Cij = 52 Aik • Bky 

k = 1 


Asterisks (*) Asterisks are used in conjunction with index markers to 
show that the operations are to be conducted on individual elements 


10 



of arrays or vectors as if they were scalars. This is often the case 
when calculating sensor values or other similar functions when mul* 
tiple scalars are grouped together for convenience. For example, the 
following equation is listed in ASP: 

The equation for measured acceleration then becomes: 

A.ACCELE RATION -M(i) = A„BI AS(i)+A.GAI N{i)*AjCOU NTE R(i) 

where i ranges from 1 to 3 and represents the three directions x, y 
and z. 

In this case, the first element of A jVCCELERATION.M would be 
calculated as follows: 

A_ACCELERATIONM{\) = A-BIAS(1)+A„GAIN(1)*AjC0UNTER(1). 

No Operator In those cases where variables, matrices, or scalars are lo- 
cated directly beside each other with no operator between, standard 
multiplication is implied. Thus two matrices collocated would be mul- 
tiplied as if they had the x operator between them, while two scalars 
would be multiplied as if they had the • operator between them. Also, 
if a scalar and a matrix (of one or more dimensions) were collocated, 
then the scalar would be multiplied by each element of the matrix and 
a new matrix of equal dimensions would be generated. 

It should be noted that throughout this specification, the words matrix 
and array are often interchanged. No significance should be placed upon the 
use of one word as opposed to use of the other. 

VEHICLE GUIDANCE 

Vehicle guidance is accomplished by varying the engine thrust so that the ve- 
hicle follows a single pre-determined velocity /altitude contour. This contour 
is made available during GCS initialization. Applying too great a decelera- 
tion early in the descent brings the vehicle velocity to its terminal value too 
high above the surface, resulting in insufficient propellant for final descent. 

Applying too small a thrust lets the vehicle impact the surface with too 
great a velocity. Either condition could be disastrous. As soon as the touch 
down sensor touches the surface, the engines are shut off. Approximately 
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ninety percent of propellant or thrust is used to minimize gravity losses; the 
remaining ten percent is used for steering. 

A gravity-turn steering law is mechanized by rotating the vehicle in pitch 
and yaw until the body’s lateral axis velocities are zero (causing the thrust 
axis to point along the total velocity vector). The action of gravity causes the 
thrust axis to rotate toward the vertical as the total velocity is reduced. An 
arbitrary roll orientation is maintained with an attitude hold mode during 
the descent. 


ENGINES 

The vehicle has three axial engines that supply the force necessary to slow 
the vehicle and allow it to safely land. Roll is controlled by three pairs of 
roll engines on the lander supplying rotational thrust. Figure 1.3 shows the 
axial and roll engines and the resulting thrust forces they impart to the 
vehicle. 

Axial Engine (Thrust) Control 

Three thrust engines first orient the vehicle so that their combined thrust 
vector opposes the vehicle’s velocity vector. Thrust (axial direction) engine 
control is a function of pitch error, yaw error, thrust error, and deviation 
from the velocity altitude contour. A combination of proportional and in- 
tegral control (PI) logic is applied to pitch and yaw control. The integral 
portion helps to reduce the steady-state pitch and yaw error. 

If no thrust error or velocity-altitude contour deviation occurs, then axial 
engine response provides only pitch and yaw control via the PI control law. 
Use of this control law implies that the overshoot problem for pitch-yaw 
control is probably small. 

Thrust control is implemented by a proportional-integral-derivative (PID) 
control law. The derivative control added here damps out overshoot. 


Roll Engine Control 

Roll control is attained by pulsing the three pairs of roll engines and is a 
function of roll angle deviation and roll rate ( p„ ) about the x axis. Roll 
engine specific impulse and thrust per unit time are constant with the in- 
tegrated thrust controlled by pulse rate. Angle deviations are controlled 
within a very small range of 0.25 to 0.35 degrees. 
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2. LEVEL 0 SPECIFICATION 
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The CCS will operate within a redundant, distributed-processing frame- 
work. It will provide an interface between the sensors (rate of descent, atti- 
tude, etc.) and the engines (roll and axial). The purpose of the CCS is to 
keep the vehicle descending along the pre-determined velocity-altitude con- 
tour which has been chosen to conserve enough fuel to effect a safe attitude 
and impact upon landing. 

The GCS effects this control by: 

• processing the following sensor information: 

— acceleration data from the three accelerometers - one for each 
vehicle axis, 

— range rate data from four splayed doppler radar beams, 

— altitude data from one altimeter radar, 

— temperature data from a solid-state temperature sensor and a 
thermocouple pair temperature sensor, 

— rates of rotation from three strapped-down gvroscopes one for 
each vehicle axis, and 

— sensing of touch down by the touch down sensor. 

• determining the appropriate commands for the axial and roll engines 
and the chute release mechanism and issuing them to keep the vehicle 
on a pre-determined velocity/altitude contour. 

The GCS also transmits telemetry data and rendezvous with GCS.SIM [10]. 
the simulator and controller. 

Versions of the GCS developed from this specification may be executed 
singly or in parallel. Output from multiple versions at various synchroniza- 
tion points will be voted to control the vehicle. One of the effects of this 
design on the specification has been a constraint to use only specific system 
services. In particular, a rendezvous routine will be provided and should 
be invoked, as specified in the implementationmotes [Appendix B]. Other 
system services and library routines are explicitly excluded from use by the 
programmers. 

When programming, the modules shown in this specification need not be 
treated as totally separate units. The programmer determines the organi- 
zation of the code with two mandatory requirements. The data stores must 
be organized as given, and the code must work within the context of the 
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timing requirements of the systeih as given. For purposes of flight system 
design, all components of the system are considered flight critical as defined 
by R'i’CA document DO- 178A[1]. 
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Figure 2.2: GCS CONTROL CONTEXT DIAGRAM 
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Figure 3.1: PROCESS 0. GCS 
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Figure 3.2: CONTROL 0. GCS 
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Table 3.1: CONTROL 0. GCS - SPECIFICATION 1 


CONTROL VARIABLE 

STATE 

Start Signal = 1 
INITJDONE = 1 
RUN-DONE = 1 

lnit.GCS 

RuruGCS 

Inactive 
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4. LEVEL 2 SPECIFICATION 
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PROCESS 1. INIT.GCS 


PURPOSE INIT.GCS initializes the guidance and control software. 
INPUT | None 

OUTPUT See Tables 7.8-7.11. 


PROCESS Init.GCS will be executed on the first call to rendezvous. 
Both Init.GCS and rendezvous will be supplied to the programmer. There 
should be a call to rendezvous prior to executing each sub-frame. The first 
call will execute Init.GCS, which will load any needed initial values for later 
use. 


• LOAD INITIAL VALUES - Load initial values for velocity, altitude, 
and attitude, as well as any others, such as the constant gains and off- 
sets that are needed. The values to be loaded in are shown in the table 
INITIALIZATION DATA in part III of the DATA DICTIONARY. 

• TURN ON SWITCHES - Turn on the Roll Engine Switch, the Touch 
Down Landing Radar Switch, and the Touch Down Sensor Switch. 

• SET FRAME COUNTER - The frame counter will be initialized to 
some number representing the next frame to be executed. This allows 
the option of starting execution at some point beyond the first frame 
of a trajectory. 
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Figure 4.2: CONTROL 2. RUN.GCS 




ASP. G3P. TSP. ARSP. TDLR.-P. TDSP. 
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Table 4.1: CONTROL 2. RUN.GCS - SPECIFICATION 1 


SCHEDULING 

Sensor Processing Sub- Frame 

■r 

ARSP 

2 

ASP 

i 

CP 

l 

GSP 

l 

TDLRSP 

2 

TDSP 

5 

TSP 

2 

Guidance Processing Sub-Frame 


CP 

1 

GP 

I 

Control Law Processing Sub-Frame 

r 

AECLP 

i 

CP 

i 

CRCP 

5 

RECLP 

1 


Above is a table listing each process in the GCS according to the subframe where 
they should be executed. A number “I” is located along with the process name. This 
number indicates that the process should be executed every “Ith” frame. Note that 
all processes are executed during frame number 1. Also note that execution of the 
GCS may begin at any frame number and should operate as if it had been running 
from the beginning of the trajectory. There are minor sequencing constraints to 
be imposed upon the modules in each subframe. During the sensor processing 
subframe, TSP should be executed before any of the other modules, and CP should 
be executed last. In the guidance and control subframes, CP should be executed 
after the other modules. Lastly, during the control subframe, AECLP needs to 
be executed before CRCP. All modules not specified here may be executed in any 
order within their subframes. On the first, and subsequent, calls to rendezvous, 
FRAME-COUNTER will be returned to the application containing the correct 
value for operation. The value in FRAME-COUNTER should be compared to the 
numbers listed below to determine if a process should be executed. As an example, 
ARSP has a number of 2, which means that it executes every other frame; while 
ASP has a number of 1, meaning it executes every frame; and TDSP has a number 
of 5 , so it executes only every fifth frame. Chapter 6 provides additional information 
on timing requirements. ^ 




Table 4.2: CONTROL 2. RUN-GCS - SPECIFICATION 2 


INPUT 

OUTPUT 

Activate 

I 

Control Variable 

Value 

Control Variable 

Value 

Process 

1 


1 




1 

ASP-DONE 

1 




1 

GSP.DONE 

i 

GP-DONE 

0 

GP 

1 

TSP.DONE 

1 




1 

TDLRSP-DONE 

1 




1 

TDSP.DONE 

1 





Table 4.3: CONTROL 2. RUN.GCS - SPECIFICATION 3 


INPUT 

T OUTPUT 1 

Activate 

mm 


Value 

Control Variable 

\~ Value 

Process 

l i 


1 

AECLP-DONE 

0 

AECLP 

1 i 


i 

RECLP-DONE 
— — 

0 1 

RECLP 

1 5 

HBBH 

j i 

CHUTE-RELEASED 

0 or 1 

CRCP 
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2.1 AECLP - Axial Engine Control Law Processing 

PURPOSE The AECLP module computes the valve settings for each 
of the three main (axial) engines. Measurements of the vehicle's velocity, 
acceleration, and roll rates are combined to produce error signals for the 
pitch, yaw, and thrust of the vehicle. These error signals are then mixed to 
produce the axial engine valve settings. 


INPUT 


A.ACCELERATION 

AEJSTATUS ' ~ 

A E.SWITCH 

A E-TEMP 

CHUTE-RELEASED 

DELTA-T 

FRAME-COUNTER 

FRAME-ENGINES JGNITED 

FULL-UP-TIME 

CONTOUR-CROSSED 

ENGINES-ON WLTITUDE 

GA 

GAX 

GP-ALTITUDE 

GP.ROTATION 

GP-VELOCITY 

GPl 

GP2 

GPY 

GQ 

GR 

GV 

GVE 

GVEI 

GVI 

GW 

GWI 

OMEGA 

PEJNTEGRAL 

PE_MAX 

PE-MIN 

TEJNTEGRAL 

TEJNIT 

TE-LIMIT 

TE_MAX 

TE_MIN 

TE-DROP 

VELOCITY-ERROR 

YEJNTEGRAL 

YE-MAX 

YE-MIN 




OUTPUT 


AE.CMD 
AE.TEMP 
PEJNTEGRAL 
TEJJMIT 


AEJSTATUS 

INTERNAL.CMD 

TEJNTEGRAL 

YEJNTEGRAL 
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PROCESS Computation of the axial engine valve settings requires the 
following steps: 

• DETERMINE IF AXIAL ENGINES ARE SWITCHED ON - 

If AE.SWITCH is set to OFF, then set AE.CMD = 0, set axial en- 
gine status to healthy and proceed directly to the step “COMMAND 
ENGINES”. 

• DETERMINE ENGINE TEMPERATURE - 

Engine temperature is determined according to the events in Table 5.1. 


Table 5.1: DETERMINATION OF AXIAL ENGINE TEMPERATURE 


Current 
Axial Engine 
Temperature 

Event 

Next 

Axial Engine 
Temperature 

Cold 

GP-ALTITUDE > Altitude to start 
engines 

Cold 

Cold 

( GP-ALTITUDE < Altitude to 
start engines ) and 
( FRAME-COUNTER - 
FRAME-ENGINES JGNITED ) • 
DELTA.T < FULL-UP-TIME 

Warming-up 

Warming_up 

( GP-ALTITUDE < Altitude to 
start engines ) and 
( FRAME-COUNTER - 
FRAME-ENGINES -IGNITED ) • 
DELTA.T > FULL-UP -TIME 

Hot 


• COMPUTE LIMITING ERRORS - 

- Compute limiting vehicle pitch (P e L ), yaw ( Y e L ), and thrust (T ^ ) 
errors using the following Proportional-Integral-Derivative (P-I- 
D) control law: c = ao + a\0 + a^XXJNTEGRAL . In 
these equations, XX JNTEGRAL = XX JN TEGRAL+ Odt 
and XX is to be replaced with one of the following; PE, YE, 
or TE depending on the type of error being calculated. Note 


34 




that t 0 is the beginning of the time step and t is the end of 
the time step; and the integration for PE and YE begins when 
the engines are turned on, while the integration for TE begins 
when the engines get hot. The terms of this control law, used for 
calculating and Y e L , are given in Table 5.2, where p v , q v , and 
r v are input as elements of GP .ROTATION; x t , y v , and z v are 
input in GPJVELOCITY; x v is input in ACCELERATION; 
and the gains are input as specified. If either PE_MIN > p e L 
or PE.MAX < P' L , then P e L should be set to either PE_MIN or 
PE-MAX respectively. Similarly, boundary values hold for Y e L 
and T'. 

The variable TE-LIM1T is provided for use in calculating T e L since 
the equation for is differential in nature, thus requires an input 
value for each time step and it is also bounded by a maximum 
and minimum value. TEXIMIT should be calculated as given in 
Table 5.2. Then T? is set to TE_MAX if TEXIMIT is greater 
than or equal to TE-MAX; or T ^ is set to TE-MIN if TEXIMIT 
is less than or equal to TE-MIN; or finally, if TEXIMIT is within 
the region bounded by TE.MAX and TE-MIX, is set equal 
to TEXIMIT. Thus TEXIMIT is not bounded by TE.MAX and 
TE.MIN, but contains a valid value for use as an input to the 
calculations during the next frame. 

Table 5.2: P t L , Y e L , and T t L CONTROL LAW COEFFICIENTS 


e 

do 

a\ 

a 2 

6 

pt 

GQ • q v 

GW 

GWI 

Zv/x'v 

Y' L 

- G R r v 

GV 

GVI 

Vv/Xv 

ZTVZZl JTTT ^oWEGATEjJJaf 

-GAX ■ x v 

GVE 

GVEI 

VELOCITY-ERROR 

GA 


• COMPUTE PITCH, YAW, AND THRUST ERRORS 

- Pitch, yaw, and thrust errors should then be calculated according 
to Table 5.3. 


. COMPUTE AXIAL ENGINE VALVE SETTINGS - 
Given a pitch, yaw, and thrust error, ( P e ,Y e ,T e ), the valve settings 
(AE.CMD) for each of the three main engines are calculated as: 
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Table 5.3: DETERMINATION OF ERROR TERMS 


AE. 

SWITCH 

CHUTE- 

RELEASED 

CONTOUR- 

CROSSED 

Pc 

n 

T e 

1 

1 

1 

n 

Y' L 

T t L 

1 

1 

0 

pt 

Yt 

TE-DROP 

1 

0 

0,1 

GQ q v 

-GR r„ 

TEJNIT 

__ o 

0,1 

0,1 

0 

0 

0 


1 

GP 1 

0 1 

\ / P* 

\ 

INTERN ALJOMD := 

GP2 

-GPY 1 

x n 



GP2 

GPY 1 

) U 

/ 


which will result in each element of the INTERNALXMD vector being 
a real value. This value should be converted into an integer value 
between 0 and 127 and placed into the appropriate element of the 
AEXMD vector. The mapping for the conversion from real to integer 
values should be as follows: 


INTERNAL.CMD 

AE.CMD 

I < 0.0 

A = 0 

0.0 < / < 1.0 

0 < A < 127 

1.0 < / 

A = 127 


with INTERNALXMD between 0 and 1.0 being converted linearly 
( with truncation ) to a value of AEXMD between 0 and 127. 

• COMMAND ENGINES - Once the correct value of AEXMD has been 
determined, it will automatically be transmitted to the engines during 
the next call to the GCS_SIM_RENDEZVOUS routine provided in 
the GCSJSIM rendezvous package. (See Appendix B. Implementation 
Notes) 

• SET AXIAL ENGINE STATUS TO HEALTHY 
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2.2 ARSP - Altimeter Radar Sensor Processing 

PURPOSE The vehicle has one altimeter radar. The ARSP module reads 
the altimeter counter provided by this radar and converts the data, into a 
measure of distance to the surface. 



A R .ALTITUDE 

AR-COUNTER 

INPUT 

AR.FREQUENCY 

K-ALT 

A R .STATUS 


OUTPUT 


AR-ALTITUDE 

AR-STATUS 

K-ALT 



PROCESS Note that A R -ALTITUDE, A R .STATUS, and K_ALT are five 
element arrays containing the present value as well as the previous four 
values of altitude, status, and state respectively. Also note that as the new 
value is calculated, it is placed into the “zeroth” position; the others are 
rotated to the (i-flst) position in the array, where i is the index of the 
current position for that value. The value whose index is out of bounds is 
dropped. The processing of the altimeter counter data (ARXOUNTER) 
into the vehicle’s altitude above the planet’s terrain depends on whether 
or not an echo is received by the altimeter radar for the current time step. 
The distance covered by the radio pulses emitted from the altimeter radar 
is directly proportional to the time between transmission and reception of 
its echo. A 10-bit digital counter (ARXOUNTER) is started as the radar 
pulse is transmitted. The counter increments AR.FREQUENCY times per 
second. The 10-bit value is placed into the lower ten bits of the 16-bit 
counter. 

• READ SENSOR - 

Upon return from the call to GCS_SIM .RENDEZVOUS prior to this 
subframe, an updated value will have been put into ARXOUNTER. 
This value should be used for the present iteration of ARSP. 

• DETERMINE ALTITUDE - When the altitude is calculated, rotate 
the AR_ALTITUDE array down by one place, and put the calculated 
value in the “zeroth” position of AR_ALTITUDE. 

- ECHO RECEIVED - 

Convert the ARXOUNTER value to a distance to be returned 
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in the variable AR.ALTITUDE by the following equation: 


A R .ALTITUDE 


AR.COV NTER ■ 3£8^ 

sec 

AR.F FREQUENCY 2 


- ECHO NOT RECEIVED - 

If an echo is not received, ARXOUXTER will return all ones. 
To smooth the estimate of altitude, fit a third-order polynomial 
to the previous four values of AR-ALTITUDE. This polynomial 
fit should then be used to extrapolate an altitude value for the 
current time step. This extrapolation should be done even if one 
or more previous values of AR.STATUS is unhealthy. In the case 
of one or more unhealthy values, the extapolated value will not 
be used, but should be calculated. 

♦ SET ALTIMETER RADAR STATUS - 
The values in AR.STATUS and K_ALT should be rotated and when 
they are calculated, the new values should be placed in the “zero” 
position as were the altitude values. Set the altimeter status accord- 
ing to Table 5.4 and determine the value of K_ALT for use in the 
GUIDANCE PROCESSOR. 
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Table 5.4: USE OF STATUS IN CALCULATION OF ALTITUDE 


CONDITION 

A ICS TAT US 

ACTION 

Echo returned 

Healthy 

K_ALT=1 

No echo returned 
but used healthy 
values in polynomial 

Failed 

K_ALT=1 

No echo returned 
and one or more 
failed values in the 
1 previous four time steps 

Failed 

K_ALT=0 


I his table is used to determine the method to calculate the altitude Each 
of the possible states of the radar is listed along with the appropriate actions 
for that situation. 
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2.3 ASP - Accelerometer Sensor Processing 


PURPOSE Three accelerometers, located at the vehicle’s center of grav- 
ity, are slightly misaligned along the vehicle’s x v ,y v , and z v axes. Each 
accelerometer produces a 16-bit binary value (AXOUNTER), represented 
as the magnitude portion of a sign magnitude number which is a linear 
function of the acceleration along its axis. The sign of the counter will al- 
ways be positive, but the offset given in AJBIAS will be negative or zero, 
so if the magnitude in A_COUNTER is smellier than that of AJ3IAS, the 
acceleration is negative. The Acceleration Sensor Processing (ASP) module 
provides measures of the vehicle accelerations through the conversion and 
digital filtering of this raw accelerometer data. 


INPUT 


A_ACCELERATION 

AXOUNTER 

A.SCALE 

ALPHA-MATRIX 

G1 


A_BIAS 

AXAINJ) 

A_STATUS 

ATMOSPHERIC-TEMP 

G2 


OUTPUT 


A_ACCELERATION 


A.STATUS 


PROCESS The processing of the accelerometer data (AXOUNTER) 
into vehicle accelerations (A-ACCELERATION) requires three steps: 

• READ ACCELEROMETER - 

Upon return from the call to GCS_SIM_RENDEZVOUS prior to this 
subframe, an updated value will have been put into AXOUNTER. 
This value should be used for the present iteration of ASP. 

• REMOVE CHARACTERISTIC BIAS - Each accelerometer has a 
characteristic DC bias (A_BIAS) which must be removed from the 
signal prior to conversion. The acceleration is a linear function of its 
AXOUNTER value where the gain specifies the slope and the offset 
(A_BIAS) specifies the intercept. 

The standard gain (AXAIN-0) must be adjusted for the effects of 
temperature prior to the conversion of the raw accelerometer values. 
The adjusted gain is a quadratic function of the ambient temperature 
(ATMOSPHERIC_TEMP) and the standard gain. 


41 


PRECEDING PAGE BLANK NOT FILMED 


— INtfNTIONAU* BLAftf 





That is. 


A.GAIN{i) := A.GAIN.O(i ) + ( GlATMOSPHERICJ'EMP ) 

+ (G2 • 

where i ranges from 1 to 3 and represents the three directions x, y, 
and z. 

Where A-GAIN.O is the standard gain. A_GAIN_0, AJ3IAS, Gl, and 
G2 are set during initialization mode. The equation for measured 
acceleration then becomes: 

ACCELERATION Jlf(i) = A-BIAS(i)+A-GAIN{i)*AJCOUNTER(i) 

where i ranges from 1 to 3 and represents the three directions x, y, 
and z. 

♦ CORRECT FOR MISALIGNMENT - Each accelerometer is slightly 
misaligned from the true vehicle axes. The following multiplier ma- 
trix, which is based on small angle approximations, corrects for this 
misalignment. The matrix is used for transforming the measured ac- 
celeration data into the true vehicle accelerations. 

( 1 ~&xz &xy \ 

<*yz 1 “ttyx 

-ot zy a zx 1 ) 


and 

ACCELERATION = ALPH A-MATRIXx ACCELERATION M 

The input variable, ALPHA-MATRIX, defines the values of the a’s 
in this multiplier matrix. For example, ALPH A_MATRIX( 1,3), a xy 
defines the angle of rotation about the vehicle’s y v axis between the 
x v axis and the misaligned x v axis. The other misalignment angles 
are defined similarly, based upon a right-handed coordinate system. 
These misalignment angles are set during GCS initialization mode. 

♦ DETERMINE ACCELERATIONS AND ACCELEROMETER STA- 
TUS - The variable A-STATUS is a four-element array in each of the 
three physical dimensions, and contains the present and previous three 
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values of status for each accelerometer. The variable A -ACCELERATION 
is a five-element array in each of the three dimensions (x, y, and z.) 
A_ACCELERATION contains the present and previous four values of 
acceleration. They are to be rotated similar to those in 2.2 ARSP. 


- If one or more of the previous three values of status is unhealthy, 
use the present value of A-ACCELERATION and set the current 
value of A.STATUS to healthy. 

- If the previous values of status are healthy, check for extreme val- 
ues and set A-STATUS and A_ACCELERATION according to 
the equations below. The accelerometer processing includes fil- 
tering of the calculated accelerations along each axis (i.e filtering 
of (x v ,y v ,z v ) t ), ignoring or eliminating calculated accelerations 
which are out of range. To effect this filtering, the means and 
standard deviations of each component of these accelerations are 
to be computed using the calculated accelerations from the pre- 
vious three time steps. That is, for the current time step t and 
the measurement of acceleration along the x axis let 




E 


1 = 2-3 



be the current sample mean and 


a 


2-1 



E 


(* v («)) 2 

3 


A 


2 


be the current sample standard deviation. If 


|/i - x v (t ) | > ASCALE * a 


then set 

x v (t) := ft 

where x v (t) is the acceleration along the x axis for the current 
time step. Similar equations hold for eliminating outliers in the 
measures of acceleration along the y and 2 axes. 
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* If the calculation for the current time step for any compo- 
nent differs from the mean by more than A .SCALE times 
the standard deviation, then that component should be re- 
placed by its current mean and A .STATUS should be set to 
unhealthy. 

* If the calculated value of acceleration is within the specified 
range of the mean, use the calculated value and place it into 
A_ACCELERATION. Then set the status to healthy. 
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2.4 CP - Communications Processing 

PURPOSE Data from the vehicle sensors and guidance processor is re- 
layed back to the orbiting platform for later analysis. The CP module con- 
verts the sensed data into a data packet appropriate for radio transmission. 


INPUT 


AE.CMD 

C-STATUS 

COMM.SYNC -PATTERN 

FRAME-COUNTER 

GUIDANCE-STATE 

RE_CMD 

SENSOR-OUTPUT 



OUTPUT 


C-STATUS 


PACKET 


PROCESS The data packet, PACKET, prepared for transmission is orga- 
nized to sequentially contain a synchronization pattern, a sequence number, 
checksum information, new sample mask, and the data itself. 

The construction of the packet requires five steps: 


• CONSTRUCT PACKET: 


GET SYNCHRONIZATION PATTERN - The synchronization 
pattern is provided in the variable COMM_SYNC_PATTERN. It 
is a 16-bit pattern dictated by the design of the receiving com- 
munications equipment. 

~ DETERMINE SEQUENCE NUMBER — The sequence number 
identifies the packet of data that is being sent. It is a byte 
value in the range 0.. 255. The sequence number will be 0 dur- 
ing the first subframe of frame number 1. Sequence numbers 
repeat after the 255th packet and can be calculated based on the 
FRAME-COUNTER and the subframe where the present call to 
CP was made. 

— PREPARE SAMPLE MASK - The sample mask is a boolean vec- 
tor where “ones” represent variables that have been sampled since 
the previous transmission. Any variables listed in Table 5.5 that 
may have changed during the present sub-frame should be marked 
in the mask and transmitted. Values that have been rotated into 
subsequent elements of an array are not considered “new” and 
thus do not have to be transmitted. This eliminates the need to 
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maintain previous values on all variables and also eliminates mak- 
ing comparisons to determine which variables should be sent. A 
position should represent each variable contained in either GUID- 
ANCE-STATE or SENSOR-OUTPUT in addition to AE.CMD 
and RE.CMD. These variables should be arranged as shown in 
Table 5.5. 

- PREPARE DATA SECTION - The data section of the packet 
contains the sixteen bit values for the elements of the variables 
in Table 5.5 that may have new samples available. Values that 
have been rotated into subsequent elements of an array are not 
considered “new” and thus do not have to be transmitted. The 
data are concatenated in the order given by the sample mask, 
starting with the most significant bit (i.e. left most bit). Vari- 
ables should be packed to the nearest byte boundary; thus, a 
single element of PACKET could contain a logical* 1 and the first 
byte of the variable that follows it. Arrays should be sent with 
the first index changing most rapidly. It should be noted that 
some arrays have terms that are constant (e.g. the off-diagonal 
terms of K-MATRIX and the diagonal terms of G-ROTATION) 
and since these terms can never have “new” values, they should 
not be transmitted. 

- CALCULATE CHECKSUM - The data checksum is calculated 
on the entire packet (excluding the checksum) using the stan- 
dard CRC-16 polynomial as defined in [11]. The calculation of 
the checksum should begin with the COMM-SYNC.PATTERN 
portion of PACKET, and conclude with the last variable to be 
sent during the current subframe. Any unused parts of PACKET 
should be ignored for the calculation of the checksum. 

• SEND PACKET - The data packet created, PACKET, will automat- 
ically be transmitted during the next call to RENDEZVOUS. 

• SET COMMUNICATOR STATUS TO HEALTHY 
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Table 5.5: PACKET VARIABLES 


AE.CMD 

AR_ALTITUDE 

A-ACCELERATION 

CONTOUR-CROSSED 

GP-ATTITUDE 

GP-VELOC1TY 

K-ALT 

RE-CMD 

TDLR-STATUS 

TD.SENSED 

VELOCITY-ERROR 


AE.STATUS 

AR-STATUS 

A.STATUS 

C-STATUS 

GP.PHASE 

G-ROTATION 

K -MATRIX 

RE-STATUS 

TDLR-VELOCITY 

TEJNTEGRAL 

YE.1NTEGRAL 


A E-TEMP 

ATMOSPHERIC-TEMP 

CHUTE-RELEASED 

GP-ALTITUDE 

GP-ROTATION 

G-STATUS 

PEJNTEGRAL 

TDLR.STATE 

TDS.STATUS 

TS-STATUS 


When read by rows, this table represents the alphabetical listing of variables 
that are to appear in the data section of the packet. 


Table 5.6: SAMPLE MASK 


INFORMATION SENT 

D 

Q 

Q 


z 

EXAMPLE MASK 

n 

n 

O 

0 

i 


Note: this table gives information only on the order of the packet. The 
packet should be packed to a byte-boundary limit into integer*2 elements. 
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Table 5.7: EXAMPLE OF PACKET 


COM M .SYNC-PATTERN 


SEQUENCE NUMBER 
SAMPLE MASK 


DATA SECTION 

containing the 
variables that 
may have changed 
since last packet 


CHECKSUM 


Note: this table is one byte wide, but any section containing three vertical 
dots represents one that may be more than one byte long (e.g. DATA 
SECTION). Also note that the variables inserted into PACKET are inserted 
in the VAX standard byte order. 
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2.5 CRCP - Chute Release Control Processing 

PURPOSE The CRCP module implements the release of the parachute 
which is attached at the beginning of the terminal descent phase. 


INPUT 


AE-TEMP 


CHUTE.RELEASED 


OUTPUT 


CHUTE_RELEASED 


PROCESS If the chute has been released, leave CHUTE-RELEASED at 
the same value and this signal will be automatically transmitted to the chute 
release mechanism during the next call to the rendezvous routine provided to 
the user (See Appendix B. Implementation Notes). If the chute has not been 
released, the engine temperature will determine whether or not to release 
the chute. If the engines are hot (i.e. AE-TEMP is HOT), then release the 
chute by setting CHUTE-RELEASED to 1. 
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2.6 GSP - Gyroscope Sensor Processing 

PURPOSE Three fiber-optic ring gyroscopes are located on the lander, 
one for each of the x, y , and z axes as shown. The Gyroscope Sensor 
Processing (GSP) module provides a measure of the vehicle’s rotation rates 
through the conversion and filtering of the raw gyroscope data. 


INPUT 


ATMOSPHERIC-TEMP 

G3 

G4 

G-CO ENTER 

G-GAIN.0 

G.OFFSET 

GJtOTATION 

G -STATUS 


OUTPUT 


G .ROTATION 


G.STATUS 


PROCESS The output from each of the gyroscope (G-COUNTER) is a 
16-bit quantity divided into 2 parts: the lower 14 bits represent the vehi- 
cle’s rate of rotation about that axis and the high-order bit represents the 
direction of this rotation. This is a sign-magnitude representation of the 
counter value that only uses the lower 14 bits of the magnitude portion of 
the number. Following is a map of GXOUNTER: 


16 

15 

14 

13 

12 

. . . 

m 

D 

X 

MAGNITUDE 


where D = direction, and X = unused. The high bit set to 1 indicates a 
negative rotation consistent with a right-handed coordinate system. 

• Rotate the values of G -ROTATION so the present values are in the 
“zeroth” position of the time dimension and the previous values are 
rotated to the (i-f 1st) position in the array, where i is the index of 
the current position for that value. The value whose index is out of 
bounds is dropped. 

• ADJUST GAIN - The standard gain (G-GAIN-0) must be adjusted 
for the effects of temperature prior to the conversion of the raw gyro- 
scope values. The adjusted gain is a quadratic function of the ambient 
temperature (ATMOSPHERIC-TEMP) and the standard gain. 
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That is, 

G-GAIN(i) := G.GAIN-O(i) + (GZ - ATMOSPHERIC J EMP) 
+ (GA • ATMOSPHERIC-TEMP 2 ) 


where i ranges from 1 to 3 and represents the three directions x, y, 
and z. 

where G-GAIN.O, G3, and G4 are set during GCS initialization mode. 

• CONVERT G-COUNTER - The rotation rate is linear with respect to 
the unprocessed gyroscope values, i.e. the lower 14 bits must be con- 
verted. G-GAIN is the multiplier for this conversion and G-OFFSET 
is the constant offset. The equation for converting counter to rotation 

then becomes: 

G -ROT AT 10 N [i) = G-OFFSET{i)+G-GAIN(i)*(G-COUNTER(i)) 

where i ranges from 1 to 3 and represents the three directions x, y, 
and z. 

• SET GYROSCOPE STATUS TO HEALTHY. 
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2.7 GP - Guidance Processing 

PURPOSE C.P uses the information available from ASP, ARSP, C'RCP, 
GSP, TDLRSP, and I DSP and the results of its previous computations to 
control the vehicle’s state during terminal descent. 


A .ACCELERATION 

A E.SWITCH 

A E.TEMP 

AR-ALTITUDE 

CHUTE-RELEASED 

CONTOUR-ALTITUDE 

CONTOUR-CROSSED 

CONTOUR-VELOCITY 

DELTA-T 

DROP-HEIGHT 

ENGINES.ONjUTITUDE 

FRAME-COUNTER 

GP-ALTITUDE 

GPJVTTITUDE 

GP.PHASE 

GP-VELOCITY 

GRAVITY 

G -ROTATION 

K_ALT 

K -MATRIX 

RE.SWITCH 

TD-SENSED 

TDLR. VELOCITY 

TDS-STATUS 


OUTPUT 


AE.SWITCH 

CONTOUR-CROSSED 

FRAME-ENGINES .IGNITED 

GP-ALTITUDE 

GP-ATTITUDE 

GP-PHASE 

GP -ROTATION 

GP-VELOCITY 

RE-SWITCH 

VELOCITY.ERROR 


ARRAYS The variables GP_ATTITUDE, GP-ALTITUDE, and 
GP_VELOCITY are five element arrays in each of their spatial dimensions 
and contain enough previous values to provide the required history for inte- 
gration in updating the vehicle and guidance states. The most recent values 
are in the array locations indexed by the lower numbers. Thus the “zero” po- 
sition represents the present values. This implies that before calculating the 
values for the present time step, all values in such arrays should be rotated 
by placing the “three” value into the “four” position, then the “two” value 
into the “three” position, etc. This will leave the “zero” position ready for 
the soon-to-be-calculated value and will discard the “four” position value. 


PROCESS The Guidance Processor computes the velocity, altitude, and 
attitude to be used in controlling the engines. 
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• SKI UP 1 UK CP ROTATION MATRIX G -ROTATION contains 
three values: p, q, and r. These values must be placed into a 3 x 3 
matrix in the correct positions for later calculations. This matrix is 
GP -ROTATION and is organized as follows: 

/ 0 r -q \ 

GP -ROT AT ION = -r 0 p 

V q -P 0 / 

Note that GP-ROTATION does not include any time histories, thus 
it may be convenient to use a temporary variable during calculation 
to hold the time histories of GP_ROTATION or to use elements di- 
rectly from G -ROTATION. However, GP-ROTATION does describe 
the correct matrix orientation for operations and upon exiting from 
GP should contain the correct values for the present time step. 

. CALCULATE NEW VALUES OF VELOCITY, ALTITUDE, AND 
ATTITUDE - 

The velocity, altitude, and attitude are each calculated by: 

1. finding a rate of change from known values then 

2. integrating this rate of change through one time step by some 
method of integration providing the accuracy specified. 

For instance: ( 

X t = Xt-i + I xdt 
Jt - 1 

where X represents the rates of change of velocity, altitude, or attitude. 
These are calculated according to the following formula: ^(variable) 
= ax Variable + /3 + correction term. Table 5.8 shows the values of 
the variables, a, /3, and the correction terms. 

Note: 

1. Gravity is given as a scalar although it is actually a vector quan- 
tity. To obtain the correct quantity, the scalar given should be 
multiplied by the last column of the GP-ATTITUDE matrix to 
produce a column vector appropriate to the equation. 

2. The equation for rate of change of altitude uses GP-ATTITUDE 
and GP-VELOCITY. The third column of GP-ATTITUDE should 
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be treated as a row for this calculation. Thus element (1,3) of 
GP_ATTITUDE becomes the first element in a vector of one row 
and three columns. The element (2,3) becomes the second ele- 
ment, and (3,3) is the third element in this vector. This row- 
vector is then multiplied by the column- vector GP.VELOCITY 
to produce a scalar. 

3. All matrices are referenced with the row being the first index, the 
column being the second index, and time being the last if there 
is a time dimension. 

The correction terms represent a difference between the guidance pro- 
cessors value and the radar’s value. The correction term is turned on 
or off by the “K” terms which are determined in the respective radar 
processors. 

• DETERMINE IF ENGINES SHOULD BE ON OR OFF - 
Axial engines should: 

E remain unchanged if GP-ALTITUDE > ENGINES-ON -ALTITUDE 

2. be set to “on” if GP JVLTITUDE < ENGINES.ON JVLTITUDE 

3. be set to “off” if GP-ALTITUDE is < DROP JIEIGHT 

4. be set to “off” if TD-SENSED is 1. 

Higher numbered conditions override lower numbered conditions; thus 
if the engines have been turned off by 3 or 4, condition 2 can never 
turn them on again. 

If the axial engines are turned on during this frame, 

FRAME_ENGINES JGNITED should be set with the current value 
of FRAME-COUNTER for the later use of AECLP in determining 
engine temperature. FRAME.ENGINES JGNITED will be initialized 
to zero, and should only be changed during the frame when the axial 
engines are turned on. 

Roll engines should be on unless the axial engines have been turned 
off due to conditions 3 or 4 above. Note that roll engines may only be 
turned off; they can never be turned on again even if neither condition 
3 nor 4 remains valid. 

Engines are turned on or off by setting the SWITCH variables to the 
appropriate values. 
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Table 5.8: DIFFERENTIAL EQUATIONS 





s 

C orrecttonT crms 


maMissxmsEm 


0 



GRAVITY . GP-ATTii l : £>£(«. 3 ) + 
A^ACC ELERATIOX 
i joei from 1 to 3 

K -M AT RI X x 
(TDLR.V ELOCITY - 
GP.V ELOCITY) 

GP-ALflTVbE ' 

0 

-GP-ATT ITU bJFx 
GP.V ELOCITY 

K -ALT • (AR-ALT ITUDE — 
GP-ALTITU DE) 


• DETERMINE VELOCITY ERROR - Calculate the difference be- 
tween the velocity of the craft and the optimal velocity of the craft at 
the vehicle altitude (Shown in Figure 5.1.) This distance is actually a 
difference between two velocities and is called VELOCITY -ERROR. 

This error term should be calculated by finding the present altitude 
in CONTOUR-ALTITUDE and using interpolation, if necessary, then 
locating the corresponding velocity in CONTOUR-VELOCITY also 
using interpolation, if necessary. VELOCITY-ERROR is used in AE- 
CLP, and it is also used to set the CONTOUR-CROSSED switch. The 
equation for VELOCITY-ERROR is given below: 

VELOCITY .ERROR = \GP-V E LOCITY\-CONTOU R.V ELOCITY 

. DETERMINE IF CONTOUR HAS BEEN CROSSED - 

If CONTOUR-CROSSED has not been set and the contour has been 
encountered, set CONTOUR-CROSSED to 1; otherwise leave it alone. 
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Figure 5.1: VELOCITY ALT IT IDE CONTOUR 
Shown are two possible trajectories, with the point along each where the 
contour is first sensed and also an example of VELOCITY-ERROR. Note: 
the altitude where the engines are turned on should be the earliest point 
to check crossing the contour, even though the trajectory may have crossed 
the contour at some greater altitude. Note that the velocity altitude con- 
tour is contained in two variables: CONTOUR-ALTITUDE and CON- 
TOUR-VELOCITY. These are both arrays with 100 elements that contain 
known points along the contour. It should be noted that the point in the 
first element is the lowest altitude given and as the index number increases, 
altitude increases. Since not all of these array elements may be needed, all 
unused elements beyond the highest given altitude will be filled with zeroes, 
and that the value of zero is never given for altitude except as this filler. The 
value of velocity at any other point may be found by linear interpolation (or 
extrapolation if the value is outside the range of the supplied contour) at 
the given vehicle altitude. 
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• DETERMINE GUIDANCE PHASE- The guidance phase (GP-PHASE) 
is determined according to the events in Table 5.9. These phases are 
based upon information that may be provided by processes other than 
the guidance processor. 


Table 5.9: GUIDANCE PHASES 



state 


■ ^1 

Hi 

Chute attached 
Engines off 

Touch down not sensed 

Altitude for turning 
engines on is sensed 

2 

Chute attached 
Engines on 

Touch down not sensed 

2 

Chute Attached 
Engines on 

Touch down not sensed 

Axial engines become hot 
and the chute is released 

|| 

Chute Released 
Axial Engines Hot 
Touch down not sensed 

2 

Chute Attached 
Engines on 

Touch down not sensed 


mm 

Chute attached 
Engines off 
Touch down sensed 

■ 

Chute released 
Axial Engines Hot 
Touch down not sensed 



Chute Released 
Engines off 

Touch down not sensed 


Chute released 
Axial Engines Hot 
Touch down not sensed 

Altitude < 

DROP -HEIGHT and 
TDS -STATUS = failed 

mm 

iHilHHR 

3 



IH 

Chute Released 
Engines off 
Touch down sensed 

4 

Chute released 
Engines off 

Touch down not sensed 

mamm 

End GCS 

Chute Released 
Engines off 
Touch down sensed 

4 

Chute released 
Engines off 

Touch down not sensed 

■ TDSjSTaTUS = failed 

End GCS 

Chute Released 
Engines off 

Touch down not sensed 


- PHASE 1 : If the altitude provided by the guidance processor is 
less than or equal to the engines-on altitude, begin Phase 2. 

- PHASE 2: If the axial engines have become hot and the parachute 

has been released, begin Phase 3. If touch down is sensed, end 

GCS. 

- PHASE 3 : If touch down has not been sensed and DROP-HEIGHT 
has not been reached, then control the axial and roll engines 
to cause the lander to follow a gravity-turn steering descent. If 
DROP -HEIGHT is reached and TDS-STATUS is healthy, begin 
Phase 4. If DROP-HEIGHT is reached and TDS-STATUS is 
failed, send final packet, and end GCS. If touch down is sensed, 
send final packet, and end GCS. 
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- PHASE 4 : If touch down has not been sensed and TDS-STATUS 
is healthj, free-fall to surface. If touch down has not been sensed 
and TDS-STATUS is failed, send final packet and end GCS. If 
touch down has been sensed, send final packet and end GCS. 

It should be noted that under certain conditions, the next phase is 
‘End GCS . This means that the implementation should stop itself at 
the end of the present sub-frame. Thus, in all cases, a clean shutdown 
of GCS implementations should end just after Communications Pro- 
cessing during the Guidance sub-frame, but before calling rendezvous. 
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2.8 RECLP - Roll Engine Control Law Processing 

PURPOSE RECLP generates the roll engine command which controls 
the firing pulse and direction of the roll engines. 


INPUT 


DELTA -T 

G-ROTATION 

PI 

P2 

P3 

P4 

RE_STATUS 

RE-SWITCH 

THETA 

THETA1 

THETA 2 



OUTPUT 


RE-CMD 

THETA 


RE-STATUS 


PROCESS Control of the lander is achieved by generating commands as 
functions of the error between a given state variable and its ideal value. 
These errors are limited and amplified to yield control values. The transfor- 
mations to accomplish this are as follows: 


• DETERMINE IF ENGINES ARE ON - If RE-SWITCH is off, then 
RE.CMD = 0; and proceed directly to commanding engines. 

• DETERMINE PULSE INTENSITY AND DIRECTION - The pulse 
intensity and direction is derived from the graph shown in Figure 5.2 
using ( p v ) t . Note that the x axis represents the integral of the roll 
rate. This is really the present angle of roll. This integral should be 
calculated by Euler’s method. As an example, THETA = THETA + 
(integral of roll for this step). Also note that when the vehicle status 
is located on a boundary between two or more roll command regions, 
the lowest intensity signal should be used to avoid over-commanding 
the engines. 


• DETERMINE ROLL ENGINE COMMAND - The pulse intensity and 
direction is packed in the lowest three lower-order bits of the actual 
roll engine command, RE-CMD as shown. 


X 

X 

X 

. . . 

X 

I 

I 

D 

16 

15 

14 


4 

3 

2 

1 
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where X = unused, I = intensity, and D = direction. I and D range in 
values as shown in the data dictionary. 

COMMAND ENGINES - 

Once RE.CMD has been set with the correct value, it will automati- 
cally be sent to the engines during the next call to GCS-SIM-RENDEZV OUS. 

SET ROLL ENGINE STATUS TO HEALTHY. 
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2.9 TDLRSP - Touch Down Landing Radar Sensor 
Processing 

PURPOSE A single touch down landing radar (TDLR) gauges the ve- 
locity of the vehicle during terminal descent. This radar is a doppler radar 
with four radar beams, each which emanates from the vehicle’s center of 
gravity with a slight offset from the vehicle’s x* v axis. The radar beams form 
the edges of the pyramid as shown in Figure 5.3 . 

The Touch Down Landing Radar Sensor Processing (TDLRSP) module 
converts measurements of the frequency shift of each beams reflection into 
vehicle velocities. The receivers associated with each beam may not find 
a usable reflection, though. If no usable reflection is found, the receiver 
returns a status of beam in search mode. 

DELTA.T FRAME-BEAM-UNLOCKED 

FRAME-COUNTER K .MATRIX 
INPUT TDLR.ANGLES TDLR.COUNTER 

TDLR.GAIN TDLR.LOCK.TIME 

TDLR.OFFSET TDLR.STATE 

TDLR-STATUS | TDLR.VELOCITY 

FRAME-BEAM-UNLOCKED I K -MATRIX 
OUTPUT TDLR.STATE TDLR.STATUS 

TDLR.VELOCITY 

L — — J 

PROCESS The value returned by each beam (TDLR.COUNTER) is 
proportional to the beam frequency shift down that beam, which is, in 
turn, proportional to the velocity down that beam. The processing of the 
TDLR.COUNTER data into the component velocities along the vehicle’s 
x, y , and z axes requires five steps. 

• ROTATE VALUES - Rearrange the values located in TDLR.VELOCITY 
and K.MATRIX so that each value is moved to the variable with the 
next larger index. Thus the values are rotated to the (i+lst) position 
in the array, where i is the index of the current position for that value. 
The value whose index is out of bounds is dropped. For example, the 
“zeroth” position is left empty for new values and the value that was 
in the “zeroth” position is now in the first position, etc. and the value 
that was in the fourth position is lost. 
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• DETERMINE RADAR BEAM STATES - The processing of the four 
radar beams depends on the state of the radar, i.e. whether or not 
each of the four beams is searching or in lock. If TDLR.STATE is 
LOCKED, and the receiver for a beam does not sense an echo (i.e. 
the beam is in search mode), the corresponding TDLR.COUNTER 
value will be zero; TDLR_STATE should be set to UNLOCKED and 
FRAME-BEAM .UNLOCKED should be set to the current frame count. 

If the previous state of TDLR.STATE is UNLOCKED, FRAME -BEAM-UNLOCKED 

should be used to ignore the beam for TDLR.LOCK.TIME seconds 

of real time, thus determining the current value of TDLR.STATE. At 

the beginning of a trajectory, FRAME.BEAM.UNLOCKED will be 

set to zero, thus meaning that the beam has never been unlocked. If 

TDLR.STATE is not UNLOCKED due to the above conditions, it 

should be set to LOCKED. 


• DETERMINE BEAM VELOCITIES - A beam velocity is a linear 
function of its TDLR.COUNTER value where the gain (TDLR.GAIN) 
specifies the slope and the offset (TDLR.OFFSET) specifies the inter- 
cept. TDLR.GAIN and TDLR.OFFSET are set during GCS initial- 
ization mode. The equation for velocity is given below. 

BEAM-VELOCITY(i) = T DLRDF FS ET +T DLR.GAIN*(TDLR.COU NTER(i)) 
where i ranges from 1 to 4 and represents the four radar beams. 


• AVERAGE BEAM VELOCITIES AND CONVERT TO BODY 
VELOCITIES - The beam velocities are resolved as specified in Table 
5.10. The resolved beam velocities are then converted to vehicle body 
velocities using the offset angles a , /? , and 7 as shown in Figure 
5.4. Note that the conversion from resolved beam velocities to body 
velocities is done with the following equations: 


B x 


B z 

COSO 


By 


By 

COS 0 


B 2 = 


Bz 


COS 7 

B x , By , B z are actually the values of the elements of TDLR.VELOCITY. 
Since the Guidance Processor needs to know which velocities it can use, 
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Table 5.10: AVERAGING DOPPLER RADAR BEAMS IN LOCK 



the K-MATRIX must be defined according to the usable velocities. 
The following equation shows the K-MATRDC in which the variables 
should be replaced with a 1 if there is a usable velocity available, or a 
0 if not as shown in Table 5.10. 

' K x 0 O' 

KMATRIX = 0 K y 0 

0 0 K z 

• SET TDLR-STATUS - Set TDLR-STATUS to healthy. 
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2.10 TDSP - Touch Down Sensor Processing 

PURPOSE The touch down sensor is attached to the end of a rod which 
is attached to the bottom of the vehicle. Its purpose is to trigger engine 
shutdown when the vehicle is at the correct distance from the surface. This 
shutdown is necessary to: 

1. avoid the stirring up of dust and debris and 

2. avoid scorching immediate area of the experiment site. 


INPUT TD.COUNTER I TDS-STATUS 


OUTPUT TD.SENSED I TDSJSTATUS 


PROCESS The touch down sensor is a simple switch at the end of a pole 
on the underside of the lander. It should normally return one of only two 
16-bit values, all ones ’ or all “zeroes”. Note that this value includes setting 
the sign bit as well as the 15 magnitude bits. 

• DETERMINE IF TOUCH DOWN HAS BEEN SENSED: 

- If all ones are returned, set TD2SENSED to 1. 

- If all zeroes are returned, set TD_SENSED to 0. 

— If any combination of “ones” and “zeroes” is returned other than 
all on or all off, assume that the sensor has failed due to electrical 
noise and set TDS-STATUS to failed. Once TDS-STATUS is set 
to failed, it should remain set to failed for all following frames. 
The normal state of the switch is all zeroes (‘off’). If all of the 
readings for the last time step are all ones (‘on’) then the current 
processed value for the sensor is ‘on’, signifying touch down has 
been sensed. At all other times, the processed value is ‘off’; thus, 
if the status is set to failed, the value should be set to ‘not sensed’, 
and the guidance processor should decide when the vehicle has 
touched down. 
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2.11 TSP - Temperature Sensor Processing 

PURPOSE A temperature gauge on the vehicle is used to adjust the 
response of the accelerometers and gyroscope. The gauge contains two tem- 
perature sensing devices: a solid-state sensor and a matched pair of thermo- 
couples. The Temperature Sensor Processing (TSP) module determines the 
ambient temperature, using either the solid-state sensor or the thermocouple 
pair in a manner maximizing the accuracy of the measurement. 


INPUT 


Ml 

M2 

M3 

M4 

SS.TEMP 

T1 

T2 

T3 

T4 

THERMO-TEMP 

TS-STATUS 



OUTPUT 


ATMOSPHERIC-TEMP I TS -STATUS 


PROCESS The processing of raw temperature data from the solid-state 
sensor and thermocouple pair, SS.TEMP and THERMO-TEMP, is based 
on the solid-state sensor being less accurate than the thermocouple pair, but 
having a greater usable operating range. The temperature values from the 
solid-state sensor are highly quantized and are used to adjust the values of 
the other sensors when they indicate temperatures outside the range of the 
thermocouple pair. 

The processing of SS.TEMP and THERMO-TEMP into an accurate 
measure of temperature (ATMOSPHERIC-TEMP) requires several steps. 
The steps are described below, but are not given in any particular order be- 
cause the steps to be taken may vary depending upon the values of SS TEMP 
and THERMO-TEMP. 


• CONVERSION OF SOLID STATE TEMPERATURE (SS.TEMP) - 
The response of the solid-state temperature sensor is linear with re- 
spect to the ambient temperature and is computed using the two cal- 
ibration points (Ml,Tl) and (M2,T‘2) which characterize the line and 
are set during GCS initialization. 

• CONVERSION OF THERMOCOUPLE PAIR TEMPERATURE 
(THERMO_TEMP) - The response of the thermocouple pair is cali- 
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brated differently depending on the region (linear or parabolic) where 
the measurement lies. See Figure 5.5. 

- THERMO .TEMP lies within the linear region - The linear region 
is bounded by the calibration points used by the thermocouple 
sensor (i.e [M3,T3] and [M4,T4] inclusive). Temperatures mea- 
sured within this region are calibrated accordingly. 

- THERMO-TEMP lies within one of the parabolic regions - The 
upper and lower parabolic regions extend plus or minus 15 per- 
cent of the difference between the measured calibration points, 
M4 and M3, respectively. These parabolic regions each intersect 
the line at the calibration points. The rate of change in tempera- 
ture, with respect to the thermocouple measurements, is contin- 
uous at these intersections. The upper (and lower) parabolas are 
defined so that the temperature goes up (or down) as the square 
of the measurement value. The parabolas are offset along both 
the temperature and measurement axes. By using the values of 
T3, T4, M3, and M4 and the fact that the function is continuous 
at the endpoints, the offsets for the parabolas may be determined; 
and the equations for the parabolas may be generated. 

SELECT MOST ACCURATE ESTIMATE - If the temperature de- 
rived from SS.TEMP falls within the accurate temperature response 
zone of the thermocouple pair, (the linear as well as parabolic regions), 
then the value returned by the thermocouple pair should be used, oth- 
erwise, the value returned by the solid-state sensor should be used. 

SET STATUS TO HEALTHY - Set the values of both elements of 
TS-STATUS to HEALTHY. 



Figure 5.5: CALIBRATION OF THERMOCOUPLE PAIR 
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6. SYSTEM TIMING AND MEMORY SPACE 
REQUIREMENTS 
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TIMING REQUIREMENTS 


The GCS must operate within certain timing constraints to be able to pro- 
vide signals to the vehicle rapidly enough to properly control the system. 
To allow the GCS to control the vehicle at the proper rate, each module 
must execute within a specified time, so that all modules to be executed 
can complete before the end of the subframe. These execution times must 
be determined by the minimum time available, which is also the time that 
the most processes are to execute. Some processes execute at a lower fre- 
quency than others; thus for some frames, there may be processes that are 
not executed, leaving extra time remaining in the frame after the last pro- 
cess finishes and before the next subframe begins. However, there will also 
be frames during which all processes execute, and thus the time allocated 
for each module is strictly limited. 


Model Time 

The GCS is part of a larger simulation that consists of GCS JSIM and one 
or more versions of the GCS. When these two parts ( GCS and GCS-SIM ) 
are combined, they approximate the behavior of the environment around a 
planetary lander ( wind, gravity, etc. ); the physical behavior of the lander 
( acceleration, engine thrust, etc. ); and the on-board control algorithms 
( GP, AECLP, etc. ). Since the experiment being conducted is interested 
in detection of software errors, the part of the simulation under study is 
only the GCS. Thus GCS becomes the “model” upon which tests will be 
conducted. For realism, constraints in timing and memory are being placed 
on GCS to simulate the restricted environment of typical embedded systems 
aboard air /spacecraft. Thus, the constraints and requirements listed that 
refer to the “model” are only those limitations being placed on a single 
version of the GCS, and the programmers should treat them as restrictions 
on their code without concern for the simulator within which their code will 
run. 

The model operates with three subframes making up each frame, and 
each frame executes within a period of DELTA.T. Therefore, each subframe 
has a duration of < DELjAji Note that returning from a call to rendezvous 
is a signal to increment the subframe. At the end of the control law process- 
ing subframe, FRAME-COUNTER will be updated by rendezvous, and the 
correct value will be returned. Figure 6.1 shows an abbreviated timeline for 
the system. 
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Response Times 

Software throughput timing shall not exceed the total time allotted for each 
frame. Synchronization points demarcate the end of each frame. 

Execution timing and memory space requirements are levied against the 
following three sub-frames per time step which occur sequentially: 

Sub-Frame I SENSOR DATA PROCESSING 
Sub- Frame II GUIDANCE PROCESSING 
Sub-Frame III ENGINE CONTROL PROCESSING 


Figure 6.1: TYPICAL TIME LINE 


INIT.GCS 


Fr»me 1 


SP 1 GP ] CLP 
Sub-frame Sub-frame Sub-frame 


Frame 2 


SP | GP | CLP 
Sub-frame Sub-frame Sub-frame 


Frame 3 


SP | GP | CLP 
Sub-frame Sub-frame Sub-frame 


run.gcs 
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Table 6.1 depicts the timing requirements per frame. 


Table 6.1: TIMING REQUIREMENTS 


SUBFRAME 

TIME 


REQUIREMENTS 

I 

tbd 

II 

tbd 

III 

tbd 


These requirements will be determined after testing of the GCS proto- 
type version is completed. 
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MEMORY SPACE REQUIREMENTS 

The memory allowed for each version will include the global space needed 
for the required data stores, as well as some space for internal variables. It 
should be remembered that the applications cannot carry any global values 
from frame to frame except those explicitly contained within the data stores. 
The values of memory sizes listed in Table 6.2 include both the global space 
and all allowable internal space for use by the applications. 

Table 6.2: MEMORY SPACE REQUIREMENTS 


SUBFRAME 

SPACE 

REQUIREMENTS 

I 

tbd 

II 

tbd 

III 

tbd 
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7. DATA REQUIREMENTS DICTIONARY 
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PART I. DATA ELEMENT DESCRIPTIONS 

The following template has been constructed for defining the data elements 
referenced in this specification: 


NAME: 

DESCRIPTION: 

USED IN: 

UNITS: 

RANGE: 

DATA TYPE: 

ATTRIBUTE: 

DATA STORE LOCATION: 
ACCURACY: 


NAME This field gives the name of the variable used in the specification. 
The variable name used during coding must be the same as specified. 

DESCRIPTION This field gives a brief description of the variable. 

USED IN This field provides a reference to the modules using this variable. 

UNITS This field indicates the unit of measure for the data contained in 
the variable being defined. 

RANGE This field specifies the permissible range of data values for the 
variable. 

DATA TYPE The data type field specifies the data type to be used when 
declaring the variable during coding. 

ATTRIBUTE This field indicates whether or not the variable contains 
data, control information, or a data condition. 

STORE LOCATION This field references the common region 
where the variable must be stored. 

ACCURACY This field dictates the degree of accuracy required for out- 
put comparisons to be made during voting . 1 

‘In the data dictionary, accuracy is listed as N/A where accuracy is not applicable, 

or TBD where accuracy is (T)o (B)e (D)etermined later. A formal modification will be’ 

released when the values of the accuracy requirements have been approved. 


85 


PRECEDES page blank not filled 




M&IIWAAU* BLAHt 



86 



NAME A-ACCELERATION 
DESCRIPTION: vehicle accelerations 
USED IN: 2 1 AECLP, 2 3 ASP, 2.7 GP 
UNITS: JB Cty 3 

RANGE: {*20, 20] 

DATA TYPE: array (1 .3, 0. 4) of real*8 
ATTRIBUTE: data 

DATA STORE LOCATION SENSOR OUTPUT 
ACCURACY: TBD 


NAME A JBI AS 

DESCRIPTION: characteristic bias in the 
accelerometer measurements 
USED IN: 2.3 ASP 
UNITS meter* 

a e 

RANGE: (-30, 0] 

DATA TYPE: array (1.3) of real*8 
ATTRIBUTE: data 

DATA STORE LOCATION RUN .PARAMETERS 
ACCURACY: N/A 


NAME A -COUNTER 

DESCRIPTION: accelerations along the f, (7 and 2 
USED IN: 2 3 ASP 
UNITS none 
RANGE:[0, 2 15 - 1) 

DATA TYPE: array (1..3) of Integer*2 
ATTRIBUTE: data 

DATA STORE LOCATION: EXTERNAL 
ACCURACY: N/A 


NAME A_G AIN.0 

DESCRIPTION: standard gain in the accelerations 
USED IN. 2.3 ASP 

UNITS e*&T 
RANGE. (0, l) 

DATA TYPE: array (1 . 3) of real*8 
ATTRIBUTE: data 

DATA STORE LOCATION: RUN -PARAMETERS 
ACCURACY: N/A 


NAME: A .SCALE 

DESCRIPTION: multiplicative constant 
used to determine limit on deviation 
accelerometer values. 

USED IN: 2 3 ASP 
UNITS: none 
RANGE (0, 2 15 - 1) 

DATA TYPE: Integer^ 

ATTRIBUTE: data 

DATA STORE LOCATION: RUN-PARAMETERS 
ACCURACY N/A 


NAME: A-STATUS 
DESCRIPTION: Flag indicating 
whether or not the accelerometers are 
working properly. 

USED IN 2 3 ASP, 2.4 CP 
UNITS: none 

RANGE; [0 ;= healthy, 1 : sun heal thy] 

DATA TYPE, array (1 .3, 0 .3) of logical^ 
ATTRIBUTE: data 

DATA STORE LOCATIONGU1DANCE-STATE 
ACCURACY: N/A 


NAME AECLP -DONE 
DESCRIPTION Flag indie a ti ng 
completion of AECLP task 
USED IN: 2. RL'N-GCS 
UNITS: none 

RANGE: (0: running of task 2 3 AECLP incomp] 
1 running of task 2.1 AECLP complete! 

DATA TYPE: logical*! 

ATTRIBUTE control 

DATA STORE LOCATION none 

ACCURACY: N/A 


NAME: AE.CMD 

DESCRIPTION Valve settings for the 
axial engines. 

USED IN: 2,1 AECLP, 2 4 CP 
UNITS: none 
RANGE: [0, 127] 

DATA TYPE, array (1 .3) of Integer*2 
ATTRIBUTE: data 

DATA STORE LOCATION: EXTERNAL 
ACCURACY TBD 


NAME AE-STATUS 
DESCRIPTION Flag indicating 
whether or not axial engines are 
working properly. 

USED IN: 2.1 AECLP, 2 4 CP 
UNITS: none 
RANGE. [0: Healthy, 

1: Failed ] 

DATA TYPE: logicai*l 

ATTRIBUTE: data condition 

DATA STORE LOCATION: GUIDANCE -STATE 

ACCURACY: N/A 


NAME: AE-SWITCH 
DESCRIPTION: Flag indicating 
whether or not axial engines are 
turned on. 

USED IN: 2.1 AECLP, 2 7 GP 
UNITS: none 

RANGE; [0: axial engines are off, 

1: axial engines are on ) 

DATA TYPE: logic 4 l"l 
ATTRIBUTE: dat4 condition 
DATA STORE LOCATION GUIDANCE 
ACCURACY: N/A 


NAME AE.TEMP 
DESCRIPTION Tempe r4ture of 
4xi4l engines when they 
4re turned on. 

USED IN. 2 1 AECLP, 2 4 CP, 2 5 CRCP 2 7 GP 
UNITS: none 

RANGE: (0: Cold, l:W4rming-Up 
2Hot] 

DATA TYPE: logical 

ATTRIBUTE: d4t4 condition 

DATA STORE LOCATION: GUIDANCE-STATE 

ACCURACY: N/A 
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NAME ALPHA-MATRIX 

DESCRIPTION Mat me of misalignment angles 
USED IN 2 3 ASP 
UNITS, none 
RANGE [-W, "■ 1 

DATA TYPE: array (13, 1 .3) o f real 8 
ATTRIBUTE: data 

DATA STORE LOCATION: RUN _PA RAMETERS 
ACCURACY: N/A 


NAME ASP-DONE 
DESCRIPTION: Flag indicating 
completion of GC3. 

USED IN: 2 RUN.GCS 
UNITS: none 

RANGE: [0: running of task 2 3 ASP incomplete, 
1: running of task 2.3 ASP complete} 

DATA TYPE logical"! 

ATTRIBUTE control 

DATA STORE LOCATION: none 

ACCURACY: N/A 


NAME. AR-ALTITUDE 
DESCRIPTION: altimeter radar height 
above terrain 

USED IN 2 2 A RSP, 2.4 CP, 2.7 GP 
UNITS: meter* 

RANGE: [0, 2000] 

DATA TYPE array (0. 4) of real"* 
ATTRIBUTE: data 

DATA STORE LOCATION: SENSOR-OUTPUT 
ACCURACY: TBD 


NAME: ATMOSPHERIC -TEMP 
DESCRIPTION: atmospheric temperature 
USED IN: 2.3 ASP, 2 4 CP, 2.6 GSP, 2 11 TSP 
UNITS: degree* centigrade 
RANGE [-250, 250] 

DATA TYPE: realM 
ATTRIBUTE: data 

DATA STORE LOCATION: SENSOR-OUTPUT, 
ACCURACY TBD 


NAME: AR-COUNTER 

DESCRIPTION counter containing elapsed time 
since tranamission of radar pulse 
USED IN 2 2 ARSP 
UNITS: Cycle* 

RANGE [-1, 2 10 - 1] 

DATA TYPE Integer*2 
ATTRIBUTE data 

DATA STORE LOCATION: EXTERNAL 
ACCURACY N/A 


NAME: CJ5TATUS 

DESCRIPTION: Flag indicating 

whether or not the communication* proce»*or i* 

working properly. 

USED IN: 2.4 CP 
UNITS: none 

RANGE: [0 := healthy, l:*failed] 

DATA TYPE: logical"l 
ATTRIBUTE: data 

DATA STORE LOCATIONGUIDANCE-oTATE 
ACCURACY: N/A 


NAME AR-FREQUENCY 
DESCRIPTION: increment frequency of 
AR_COUNTER 
USED IN: 2.2 ARSP 

UN'TS 

RANGE [1, 10 9 ] 

DATA TYPE: real"8 
ATTRIBUTE data 

DATA STORE LOCATION: RUN -PARAMETERS 
ACCURACY N/A 


NAME: CHUTE-RELEASED 
DESCRIPTION: signal indicating parachute 
ha* been relea*ed 

USED IN: 2 1 AECLP, 2.4 CP, 2.5 CRCP, 2.7 GP 
UNITS: none 

RANGE: (0: Chute Attached, 

1: Chute Released] 

DATA TYPE: logical*l 

ATTRIBUTE data condition 

DATA STORE LOCATION: GUIDANCE-STATE 

irrnn irv St A 


NAME: AR-STATUS 

DESCRIPTION; statu* of the altimeter radars 
USED IN: 2.2 ARSP. 2 4 CP 
UNITS: none 

RANGE: (0 = healthy, 1 =failed] 

DATA TYPE array (0. 4) of logical"! 
ATTRIBUTE data 

DATA STORE LOCATION GUIDANCE-STATE 
ACCURACY N/A 


NAME COMM-SYNC-PATTERN 

DESCRIPTION: sixteen bit synchronisation pattern 
USED IN: 2 4 CP 
UNITS none 

RANGE: lUOllOOnOllOOlO] 

DATA TYPE Integer"2 
ATTRIBUTE: data 

DATA STORE LOCATION; RUN-PARAMETERS 
ACCURACY: N/A 


NAME: ARSP.DONE 
DESCRIPTION Flag indicating 
completion of ARSP task. 

USED IN: 2 RUN-GCS 
UNITS; none 

RANGE: [0 running of task 2 2 ARSP incomplete, 
1; running of task 2 2 ARSP complete] 

DATA TYPE: logical*l 
ATTRIBUTE: control 
DATA STORE LOCATION: none 
ACCURACY: N/A 


NAME: CONTOUR-ALTITUDE 

DESCRIPTION Altitude in Velocity-altitude contour 
( the h in V(h)* ) 

USED IN: 2.7 GP 
UNITS: kilometers 
RANGE: [0, 2] 

DATA TYPE array (1 .100) of real"8 
ATTRIBUTE: data 

DATA STORE LOCATION: RUN-PARAMETERS 
ACCURACY N/A 
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NAME: CONTOUR .CROSS ED 
DESCRIPTION: Indicates if the velocity 
altitude contour has been sensed 
USED IN: 2 1 AECLP 2 4 CP, 2 7 GP 
UNITS: none 

RANGE: [0:= contour not sensed, 1:= contour sensed] 

DATA TYPE: logicaPl 

ATTRIBUTE: data condition 

DATA STORE LOCATION GUIDANCE-STATE 

ACCURACY: N/A 


NAME: ENGINES-ON.ALTITU DE 
DESCRIPTION: Altitude at 
which the axial engines are 
turned on. 

USED IN: 2.1 AECLP, 2 7 GP 
UNITS: meters 
RANGE: (0, 2000] 

DATA TYPE: reaPS 

ATTRIBUTE: data condition 

DATA STORE LOCATION: RUN-PARAMETERS 

ACCURACY: N/A 


NAME; CONTOUR-VELOCITY 

DESCRIPTION: Velocity in Velocity-altitude contour 

( the V in 'V(h)’ ) 

USED IN: 2.7 GP 

UNITS: MlgPIClyj 
second 

RANGE: [0, 0.5] 

DATA TYPE: array (1. 100) of real*8 
ATTRIBUTE: data 

DATA STORE LOCATION: RUN-PARAMETERS 
ACCURACY: N/A 


NAME: FRAME-BEAM-UNLOCKED 
DESCRIPTION: Variable containing the number 
of the frame during which the radar beam 
unlocked 

USED IN; 2.9 TDLRSP 
UNITS: none 
RANGE [0, 2 31 - 1] 

DATA TYPE: array (1 .4) of Integer*4 
ATTRIBUTE: data 

DATA STORE LOCATION GUIDANCE 
ACCURACY: TBD 


NAME: CP_DONE 
DESCRIPTION: Flag indicating 
completion of 2 4 CP task 
USED IN: 2 RUN-GCS 
UNITS: none 
RANGE (0 running of task 2 4 CP incomplete, 
1: running of task 2 4 CP complete] 

DATA TYPE logicaPl 
ATTRIBUTE, control 
DATA STORE LOCATION: none 
ACCURACY: N/A 


NAME: FRAME-COUNTER 
DESCRIPTION: Counter containing the number 
of the present frame 
USED IN: 2.1 AECLP, 2.4 CP, 

2.7 GP, 2.9 TDLRSP 
UNITS: none 
RANGE: [1, 2 31 - 1] 

DATA TYPE: Integer-* 

ATTRIBUTE: data 

DATA STORE LOCATION: EXTERNAL 
ACCURACY: TBD 


NAME CRCP.DONE 
DESCRIPTION: Flag indicating 
completion of 2 5 CRCP task 
USED IN 2. RUN-GCS 
UNITS: none 

RANGE: [0 running of task 2.5 CRCP incomplete, 
1 running of task 2.5 CRCP complete) 

DATA TYPE: logical*] 

ATTRIBUTE: control 

DATA STORE LOCATION none 

ACCURACY: N/A 


NAME: FRAME-ENGINES-IGNITED 
DESCRIPTION: Variable containing the number 
of the frame during which the engines 
were ignited 

USED IN: 2.1 AECLP, 2.7 GP 
UNITS: none 
RANGE: (0, 2 31 - 1] 

DATA TYPE: Integer-4 
ATTRIBUTE: data 

DATA STORE LOCATION: GUIDANCE 
ACCURACY: TBD 


NAME: DELTA.T 
DESCRIPTION: Time step duration 

USED IN 2 1 AECLP, 2 7 GP, 2.8 RECLP, 2 9 TDLRSP NAME FULL-UP-TIME 

DESCRIPTION. Time for axial engines to reach 
optimum operational condition 


UNITS seconds 


RANGE (0, 0 20] 

DATA TYPE real*8 
ATTRIBUTE data 

DATA STORE LOCATION: RUN-PARAMETERS 
ACCURACY: N/A 


NAME: DROP-HEIGHT 

DESCRIPTION: Height from which vehicle should 

free-fall to surface 

USED IN: 2.7 GP 

UNITS: meters 

RANGE: [0, 100] 

DATA TYPE: real's 
ATTRIBUTE: data 

DATA STORE LOCATION RUN-PARAMETERS 
ACCURACY N/A 


USED IN 2.1 AECLP 
UNITS: seconds 
RANGE; (0, 60) 

DATA TYPE: reaP8 
ATTRIBUTE: data 

DATA STORE LOCATION: RUN -PARAMETERS 
ACCURACY: N/A 
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NAME Gl 

DESCRIPTION coefficient used to Adjust A.GAIN 
USED IN 2 3 ASP 


meter j 
de grecC 


RANGE; [-5, 5] 
DATA TYPE: real*8 


ATTRIBUTE data 
DATA STORE LOCATION 
ACCURACY N/A 


RUN PARAMETERS 


NAME G.GAIN.O 

DESCRIPTION standard gain in vehicle rotation 
rales as measured by the gyroscopes 

USED IN 2 6 GSP 


UNITS, 

RANGE: [-1, 1] 

DATA TYPE array (1. 3) of real*8 
ATTRIBUTE data 

DATA STORE LOCATION: RUNPARAMETERS 
ACCURACY N/A 


NAME: G2 

DESCRIPTION: coefficient used to adjust A-GAIN 
USED IN: 2 3 ASP 
mctcra 

UNITS: aficgnd 2 , 

dtgrttC 1 
RANGE: (-5, 5) 

DATA TYPE real*8 
ATTRIBUTE data 

DATA STORE LOCATION: RUNPA RAMETERS 
ACCURACY N/A 


NAME: G-OFF5ET 

DESCRIPTION standard offset of the 
ROTATION PAW values 
USED IN: 2 6 GSP 
UNITS 

RANGE: (-0.5, 0.5) 

DATA TYPE: array (1-3) of real*8 
ATTRIBUTE: data 

DATA STORE LOCATION: RUNPARAMETERS 
ACCURACY: N/A 


NAME. G3 

DESCRIPTION: coefficient used to adjust G_GAIN 
USED IN: 2.6 GSP 

radians 

RANGE (-3, 5] 

DATA TYPE real** 

ATTRIBUTE data 

DATA STORE LOCATION RUNPARAMETERS 
ACCURACY N/A 


NAME GPOTATION 

DESCRIPTION vehicle rotation rates 

USED IN 2 4 CP, 2 6 GSP, 2.7 GP, 2.8 RECLP 

UNITS rft j^ n< 

RANGE: [-5 0, 5 0) 

DATA TYPE: array (13, O..4)of real*8 
ATTRIBUTE: data 

DATA STORE LOCATION: SENSOR-OUTPUT 
ACCURACY: TBD 


NAME: G4 

DESCRIPTION: coefficient used to adjust G-GAIN 


USED IN: 2.6 GSP 
radians 

UNITS: lfi £. gnj , 

de jreeC* 

RANGE (-5, 5] 

DATA TYPE real“8 
ATTRIBUTE data 
DATA STORE LOCATION 
ACCURACY: N/A 


RUNPARAMETERS 


NAME: G-COUNTER 

DESCRIPTION gyroscope measurement of vehicle 
rotation rates 
USED IN 2 6 GSP 
UNITS: none 

RANGE: l-(2 W - 1). 2 14 - 1) 

DATA TYPE array (1 .3) of Integer*2 
ATTRIBUTE data 

DATA STORE LOCATION EXTERNAL 
ACCURACY: N/A 


NAME G-STATUS 

DESCRIPTION status of the gyroscopes 
USED IN: 2.4 CP, 2.6 GSP 
UNITS: none 

RANGE [0 :a healthy, l: = failed) 

DATA TYPE: lojical*l 
ATTRIBUTE: data 

DATA STORE LOCATION: GUIDANCE-STATE 
ACCURACY: N/A 


NAME; GA 
DESCRIPTION gain 
USED IN: 2.1 AECLP 
UNITS 

RANGE: (0, 50) 

DATA TYPE real*8 
ATTRIBUTE: data 

DATA STORE LOCATION: RUNPARAMETERS 
ACCURACY: N/A 


NAME G AX 
DESCRIPTION gain 
USED IN: 2.1 AECLP 
UNITS: none 
RANGE [0, 15000) 

DATA TYPE real*8 
ATTRIBUTE: data 

DATA STORE LOCATION: RUNPARAMETERS 
ACCURACY: N/A 
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NAME GPl 
DESCRIPTION: gain 
USED IN: 2.1 AECLP 
UNITS none 
RANGE: [-5, 5] 

DATA TYPE: real*8 
ATTRIBUTE: data 

DATA STORE LOCATION: RUN -PARAMETERS 
ACCURACY: N/A 


NAME: GP2 
DESCRIPTION: gain 
USED IN 2.1 AECLP 
UNITS: none 
RANGE: [-5, 5] 

DATA TYPE: real-8 
ATTRIBUTE: data 

DATA STORE LOCATION: RUN -PARAMETERS 
ACCURACY: N/A 


NAME: GP-A LT1TUDE 
DESCRIPTION: altitude a$ seen by 
guidance processor 

USED IN: 2 1 AECLP, 2.4 CP, 2.7 GP 
UNITS meter* 

RANGE: [0, 2500} 

DATA TYPE: array (0..4) of real*8 
ATTRIBUTE: data 

DATA STORE LOCATION: GUIDANCE-STATE 
ACCURACY: TBD 


NAME: GP.ATTITUDE 
DESCRIPTION, attitude at seen by 
guidance processor 
USED IN: 2.4 CP, 2.7 GP 
UNITS: none 
RANGE: |-1, 1] 

DATA TYPE: array (1.3, 13, 0..4) reai*8 
ATTRIBUTE, data 

DATA STORE LOCATION: GUIDANCE-STATE 
ACCURACY: TBD 


NAME GP-DONE 
DESCRIPTION Flag indicating 
completion of 2 7 GP task. 

USED IN: 2. RUN-GCS 
UNITS: none 

RANGE [0 running of task 2 7 GP incomplete, 
1 running of talk 2.7 GP complete] 

DATA TYPE: logicafl 
ATTRIBUTE control 
DATA STORE LOCATION: none 
ACCURACY: N/A 


NAME GP-PHASE 

DESCRIPTION: phase of operation ai seen by 

guidance processor 

USED IN: 2.4 CP, 2.7 GP 

UNITS, none 

RANGE: {1, 4) 

DATA TYPE: integer*4 
ATTRIBUTE: data 

DATA STORE LOCATION GUIDANCE-STATE 
ACCURACY: TBD 


NAME GP .ROTATION 

DESCRIPTION rotation rate* as determined by 
the guidance processing module 
USED IN: 2.1 AECLP, 2 4 CP, 2.7 GP 
UNITS raci ' ans 
RANGE [-5*5] 

DATA TYPE array (1..3, 1 .3) real*8 
ATTRIBUTE: data 

DATA STORE LOCATION: GUIDANCE-STATE 
ACCURACY TBD 


NAME: GP.VELOCITY 
DESCRIPTION: Velocity as corrected by 
the guidance algorithm. 

USED IN: 2.1 AECLP, 2 4 CP, 2.7 GP 
UNITS: Tntttra 
RANGE {*100, 100] 

DATA TYPE: array ( 13, 0 4) of real-8 
ATTRIBUTE: data 

DATA STORE LOCATION: GUIDANCE -STATE 
ACCURACY: TBD 


NAME: GP Y 
DESCRIPTION: gain 
USED IN: 2.1 AECLP 
UNITS: none 
RANGE (*5, 5] 

DATA TYPE: real-8 
ATTRIBUTE: data 

DATA STORE LOCATION: RUN-PARAMETERS 
ACCURACY: N/A 


NAME: GQ 
DESCRIPTION: gain 
USED IN: 2.1 AECLP 
UNITS: second* 

RANGE: (*S, 5] 

DATA TYPE: real*8 
ATTRIBUTE: data 

DATA STORE LOCATION: RUN-PARAMETERS 
ACCURACY: N/A 


NAME GR 
DESCRIPTION gain 
USED IN 2.1 AECLP 
UNITS seconds 
RANGE: [-5, 5] 

DATA TYPE: real-8 
ATTRIBUTE: data 

DATA STORE LOCATION: RUN-PARAMETERS 
ACCURACY N/A 


NAME GRAVITY 
DESCRIPTION: gravity of planet 
USED IN: 2.7 GP 
UNITS: -Qictira 
second 2 
RANGE: [0, 100] 

DATA TYPE: real-8 
ATTRIBUTE: data 

DATA STORE LOCATION: RUN-PARAMETERS 
ACCURACY: N/A 
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NAME. GSP JDONE 
DESCRIPTION: Flag indicating 
completion of 26 GSP task 
USED IN 2 RUN.GCS 
UNITS Binary 

RANGE: [0 running of task 2 6 GSP incomplete, 
1: running of task 2 6 GSP complete] 

DATA TYPE logical'l 
ATTRIBUTE control 
DATA STORE LOCATION none 
ACCURACY N/A 


NAME: GW 
DESCRIPTION gain 
USED IN: 2 1 AECL.P 
UNITS. 

RANGE (-5, 5] 

DATA TYPE real'8 
ATTRIBUTE data 

DATA STORE LOCATION: PUN _PARAM ETERS 
ACCURACY N/A 


NAME: GUIDANCE -STATE 
DESCRIPTION Data »tore containing all 
the status, state, and sensed variables 
in alphabetical order 

USED IN 21 AECLP, 2 2 ARSP, 2 3 ASP. 2 4 CP, 

2.5 CRCP, 2.6 GSP, 2.7 GP, 2.8 RECLP, 2 9 TDLRSP, 

2.10 TDSP, 2.11 TSP UNITS: N/A 

RANGE N/A 

DATA TYPE; common 

ATTRIBUTE: data store 

DATA STORE LOCATION: GUIDANCE -STATE 
ACCURACY: N/A 


NAME: GV 
DESCRIPTION gain 
USED IN 2 1 AECLP 


UNITS: 

RANGE: FI, 5] 
DATA TYPE real's 


ATTRIBUTE data 
DATA STORE LOCATION: 
ACCURACY N/A 


RUN-PARAMETERS 


NAME GVE 
DESCRIPTION: gain 
USED IN 2.1 AECLP 
UNITS: /second 
RANGE [-10V 10 4 ] 

DATA TYPE real's 
ATTRIBUTE data 

DATA STORE LOCATION: RUN-PARAMETERS 
ACCURACY N/A 


NAME: GW1 
DESCRIPTION: gain 
USED IN: 2 1 AECLP 
UNITS: /meter 
RANGE [-5, 5] 

DATA TYPE: real*8 
ATTRIBUTE, data 

DATA STORE LOCATION: RUN -PARA METERS 
ACCURACY N/A 


NAME I NIT -DONE 
DESCRIPTION: Flag indicating 
completion of GCS initialization. 

USED IN: 0 GCS 
UNITS: none 

RANGE: (0: initialization incomplete, 
1: initialization complete] 

DATA TYPE: logical'l 
ATTRIBUTE control 
DATA STORE LOCATION: none 
ACCURACY: N/A 


NAME: INTERN A L-CMD 
DESCRIPTION: Real vector containing 
the command to be sent to the axial 
engines 

USED IN; 2.1 AECLP 
UNITS none 
RANGE [-5, 5] 

DATA TYPE array (13) of real's 
ATTRIBUTE data 

DATA STORE LOCATION: GUIDANCE 
ACCURACY TBD 


NAME; GVE1 
DESCRIPTION: gain 
USED IN: 2 1 AECLP 
UNITS: /second 2 
RANGE [-5, 5) 

DATA TYPE: real's 
ATTRIBUTE: data 

DATA STORE LOCATION RUN .PARAMETERS 
ACCURACY: N/A 


NAME: K.ALT 

DESCRIPTION Determines use of altimeter radar 

by guidance processor 

USED IN: 2.2 ARSP, 2.4 CP, 2 7 GP 

UNITS none 

RANGE: (0, 1] 

DATA TYPE array (0 4) of Integer'4 
ATTRIBUTE data 

DATA STORE LOCATION: GUIDANCE .STATE 
ACCURACY N/A 


NAME: GVI 
DESCRIPTION: gain 
USED IN; 2.1 AECLP 
UNITS; /meter 
RANGE [-5, 5] 

DATA TYPE: real's 
ATTRIBUTE data 

DATA STORE LOCATION RUN -PARAMETERS 
ACCURACY: N/A 


NAME: K-MATRIX 

DESCRIPTION; Determine* use of doppler radar 
by guidance processor. 

USED IN 2 4 CP, 2 7 GP, 2.9 TDLRSP 
UNITS: none 
RANGE; [0, 1] 

DATA TYPE array (13, 1. 3, 0..4) In»eger'4 
ATTRIBUTE: data 

DATA STORE LOCATION: GUIDANCE-STATE 
ACCURACY N/A 


92 



NAME: Ml 

DESCRIPTION lower measured temperature 

calibration point for solid state 

temperature senior 

USED IN 2 11 TSP 

UNITS none 

RANGE [0 2 15 - 1] 

DATA TYPE Integer-2 
ATTRIBUTE data 

DATA STORE LOCATION: RUN -PARAMETERS 
ACCURACY N/A 


NAME: M2 

DESCRIPTION: upper measured temperature 

calibration point for solid state 

temperature sensor 

USED IN 2 11 TSP 

UNITS: none 

RANGE: [0, 2 15 - lj 

DATA TYPE: lnteger-2 

ATTRIBUTE: data 

DATA STORE LOCATION: RUN-PARAMETERS 
ACCURACY N/A 


NAME M3 

DESCRIPTION: lower measured temperature 

calibration point for ihermocouple pair 

temperature sensor 

USED IN 2.11 TSP 

UNITS none 

RANGE (0, 2 15 - 1] 

DATA TYPE Integer-2 
ATTRIBUTE data 

DATA STORE LOCATION RUN -PARAMETERS 
ACCURACY N/A 


NAME M4 

DESCRIPTION: upper measured temperature 

calibration point for thermocouple pair 

temperature sensor 

USED IN 2.11 TSP 

UNITS none 

RANGE (0, 2 15 - lj 

DATA TYPE Integer-2 

ATTRIBUTE data 

DATA STORE LOCATION RUN-PARAMETERS 
ACCURACY N/A 


NAME OMEGA 
DESCRIPTION: gain of 
angular velocity 
USED IN 2.1 AECLP 
UNITS: /second 
RANGE [-50, 50] 

DATA TYPE: reaJ-8 
ATTRIBUTE: data 

DATA STORE LOCATION RUN-PARAMETERS 
ACCURACY N/A 


NAME: PI 

DESCRIPTION: pulse rate boundary 
USED IN 2 8 RECLP 
UNITS: radians/sec 
RANGE: [0, 0 05] 

DATA TYPE: real-8 
ATTRIBUTE data 

DATA STORE LOCATION: RUN _PA RA M ETERS 
ACCURACY: N/A 


NAME P2 

DESCRIPTION: pulse rate boundary 
USED IN: 2.8 RECLP 
UNITS: radians/sec. 

RANGE: (0, 0 05] 

DATA TYPE: real*8 
ATTRIBUTE: data 

DATA STORE LOCATION: RUN-PARAMETERS 
ACCURACY: N/A 


NAME: P3 

DESCRIPTION: pulse rate boundary 
USED IN 2 8 RECLP 
UNITS radians/sec 
RANGE (0, 0.05] 

DATA TYPE: real*8 
ATTRIBUTE: data 

DATA STORE LOCATION: RUN .PARAMETERS 
ACCURACY: N/A 


NAME: P4 

DESCRIPTION: pulse rate boundary 
USED IN: 2.8 RECLP 
UNITS: radians/sec. 

RANGE: [0, 0 05] 

DATA TYPE real*8 
ATTRIBUTE: data 

DATA STORE LOCATION: RUN-PARAMETERS 
ACCURACY: N/A 


NAME: PACKET 

DESCRIPTION: Packet of telemetry data 
USED IN: 2 4 CP 
UNITS N/A 
RANGE: N/A 

DATA TYPE: array (1 256) of lnteger-2 
ATTRIBUTE data 

DATA STORE LOCATION EXTERNAL 
ACCURACY: N/A 


NAME: PE JNTEGRAL 
DESCRIPTION Integral portion of Pitch 
error equation 

USED IN: 2 1 AECLP, 2 4 CP 
UNITS: meter. 

RANGE: [-1000, 1000] 

DATA TYPE real-8 
ATTRIBUTE: data 

DATA STORE LOCATION: GUIDANCE-STATE 
ACCURACY: TBD 
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NAME: PE-MAX 

DESCRIPTION Maximum pilch error tolerable 
USED IN: 2 1 AECLP 
UNITS: none 
RANGE [0, I] 

DATA TYPE real'8 
ATTRIBUTE: data 

DATA STORE LOCATION RU N _PARA M ETERS 
ACCURACY: N/A 


NAME; P E-MIN 

DESCRIPTION: Minimum pilch error tolerable, 
USED IN: 2 1 AECLP 
UNITS: none 
RANGE (-1, 0] 

DATA TYPE: real's 
ATTRIBUTE: data 

DATA STORE LOCATION: RUN-PARAMETERS 
ACCURACY: N/A 


NAME: RE-CMD 

DESCRIPTION: roll engine command 
USED IN: 2.4 CP, 2 6 RECLP 
UNITS: none 

RANGE: D (direction)[0=po*itive, l=negative] 

I (intensity) [0 = off, l=minimum. 2=intermediate, 
3 = maximum) 

DATA TYPE lnteger'2 
ATTRIBUTE: data 

DATA STORE LOCATION: EXTERNAL 
ACCURACY: TBD 


NAME: RE-STATUS 

DESCRIPTION: atatu* of the roll engine* 

USED IN: 2.4 CP, 2 8 RECLP 
UNITS: none 

RANGE: [0 :* healthy. l: = failed] 

DATA TYPE: logical'l 
ATTRIBUTE: data 

DATA STORE LOCATION GUIDANCE-STATE 
ACCURACY N/A 


NAME: RE-SWITCH 
DESCRIPTION: Flag indicating 
whether or not the roll engine* are 
turned on 

USED IN INIT-GCS, 2.7 GP 
UNITS: none 

RANGE (0 roll engine* are off, 

1 roll engine* are on ] 

DATA TYPE logical'l 
ATTRIBUTE: data condition 
DATA STORE LOCATION GUIDANCE 
ACCURACY N/A 


NAME: RECLP-DONE 
DESCRIPTION: Flag indicating 
completion of 2.8 RECLP ta*k 
USED IN 2 RUN-GCS 
UNITS: none 

RANGE: [0: running of ta*k 2 8 RECLP incomplete, 
1: running of ta*k 2 6 RECLP complete) 

DATA TYPE logical'l 
ATTRIBUTE: control 
DATA STORE LOCATION none 
ACCURACY N/A 


NAME RUN-DONE 
DESCRIPTION Flag indicating 
completion of GCS. 

USED IN 0 GCS 
UNITS: none 

RANGE: [0: running of GCS incomplete, 
1 running of GCS complete) 

DATA TYPE logical'l 
ATTRIBUTE control 
DATA STORE LOCATION, none 
ACCURACY: N/A 


NAME: RUN-PARAMETERS 
DESCRIPTION Data *tore containing all 
the run parameter* in alphabetical order. 

USED IN 2 2 ARSP, 2.3 ASP, 2.6 GSP, 

2.9 TDLRSP, 2 10 TDSP, 2 11 TSP 

UNITS: N/A 

RANGE: N/A 

DATA TYPE common 

ATTRIBUTE data More 

DATA STORE LOCATION RUN -PARAMETERS 
ACCURACY N/A 


NAME: SENSOR-OUTPUT 
DESCRIPTION: Data *tore containing all 
the *en*or output in alphabetical order. 

USED IN: 2 2 ARSP, 2 3 ASP, 2 4 CP 

2.6 GSP, 2.9 TDLRSP, 2.10 TDSP, 2.11 TSP 

UNITS: N/A 

RANGE: N/A 

DATA TYPE common 

ATTRIBUTE: data *tore 

DATA STORE LOCATION: SENSOR-OUTPUT 
ACCURACY N/A 


NAME SS.TEMP 

DESCRIPTION: Solid *tale temperature data 

USED IN: 2.11 TSP 

UNITS: none 

RANGE: (0, 2 15 - ll 

DATA TYPE Integer*2 

ATTRIBUTE data 

DATA STORE LOCATION EXTERNAL 
ACCURACY N/A 


NAME; T1 

DESCRIPTION lower ambient temperature 

calibration point for *olid atate 

temperature »en*or 

USED IN: 3.11 TSP 

UNITS: degree* Centigrade 

RANGE: [-230, 230) 

DATA TYPE real*6 
ATTRIBUTE data 

DATA STORE LOCATION: RUN -PARAMETERS 
ACCURACY: N/A 
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NAME T2 

DESCRIPTION upper ambient temperature 

calibration point for aolid state 

temperature sensor 

USED IN 2.11 TSP 

UNITS: degrees Centigrade 

RANGE [-250, 250] 

DATA TYPE: real*8 
ATTRIBUTE: data 

DATA STORE LOCATION RUN-PARAMETERS 
ACCURACY: N/A 


NAME TDLR-ANGLES 

DESCRIPTION vector of doppler radar beam 
offset angles (i.e , a , 0, y ) 

USED IN 2 9 TDLRSP 
UNITS: radians 
RANGE: [0, jj 

DATA TYPE: array (1 3) real*8 
ATTRIBUTE: data 

DATA STORE LOCATION RUN-PARAMETERS 
ACCURACY: N/A 


NAME: T3 

DESCRIPTION: lower ambient temperature 

calibration point for thermocouple pair 

temperature sensor 

USED IN 2.11 TSP 

UNITS; degrees Centigrade 

RANGE: [-50, 50] 

DATA TYPE: real*6 
ATTRIBUTE: data 

DATA STORE LOCATION RUN _PARAM ETERS 
ACCURACY N/A 


NAME- TDLR-COUNTE R 

DESCRIPTION: value returned by Doppler radar 
USED IN: 2.9 TDLRSP 
UNITS: none 
RANGE [0, 2 15 - 1 ] 

DATA TYPE array (1..4) Integer*2 
ATTRIBUTE: data 

DATA STORE LOCATION: EXTERNAL 
ACCURACY N/A 


NAME: T 4 

DESCRIPTION: upper ambient temperature 

calibration point for thermocouple pair 

temperature sensor 

USED IN 2.11 TSP 

UNITS: degrees Centigrade 

RANGE: [-50, 50] 

DATA TYPE real*8 
ATTRIBUTE: data 

DATA STORE LOCATION: RUN_PARAMETERS 
ACCURACY; N/A 


NAME: TD .COUNTER 

DESCRIPTION: value returned by Touch Down Sensor 
USED IN: 2.10 TDSP 
UNITS; none 

RANGE; [-2 15 , 2 15 - l ] 

DATA TYPE: Integer^ 

ATTRIBUTE: data 

DATA STORE LOCATION EXTERNAL 

ACCURACY: N/A 


NAME: TD-SENSED 
DESCRIPTION: Flag indicating 
whether or not touch down has 
been sensed. 

USED IN 2.4 CP, 2.7 GP, 2 10 TDSP 
UNITS: none 

RANGE [0: touch down not sensed, 

1 touch down sensed] 

DATA TYPE: logical*! 

ATTRIBUTE: data condition 

DATA STORE LOCATION SENSOR-OUTPUT 

ACCURACY: N/A 


NAME: TDLR.GAIN 

DESCRIPTION: gain in doppler radar beam 
USED IN: 2.9 TDLRSP 


UNITS: -icVgrid 
RANGE fl“?/ 

DATA TYPE: real*8 
ATTRIBUTE: data 

DATA STORE LOCATION RUN _PA RA M ETERS 
ACCURACY: N/A 


NAME: TDLR-LOCK.TIME 

DESCRIPTION. locking time of doppler radar beam 
USED IN; 2.9 TDLRSP 
UNITS: seconds 
RANGE: [0, 80] 

DATA TYPE: re*l*8 
ATTRIBUTE data 

DATA STORE LOCATION; RUN -PARAMETERS 
ACCURACY N/A 


NAME: TDLRjOFFSET 

DESCRIPTION offset in doppler radar beam 
USED IN: 2 9 TDLRSP 

UNITS: meferj 
second 

RANGE: (-100, 0] 

DATA TYPE: real*8 
ATTRIBUTE: data 

DATA STORE LOCATION: RUN PARAMETERS 
ACCURACY N/A 


NAME TDLR.STATE 

DESCRIPTION: slate of the touch down landing 
radar beams. 

USED IN: 2 4 CP, 2.9 TDLRSP 
UNITS: none 

RANGE: [0: Beam out of Lock, 

1: Beam in lock] 

DATA TYPE array (1..4) logical*! 

ATTRIBUTE: data condition 

DATA STORE LOCATION: GUIDANCE -STATE 

ACCURACY: N/A 
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NAME: TDLRJ3TATUS 

DESCRIPTION status of the doppler radar 
USED IN 2 4 CP, 2 9 TDLRSP 
UNITS: none 

RANGE: (0 := healthy, l: = failed] 

DATA TYPE array (1. 4) of logicaI*l 
ATTRIBUTE data 

DATA STORE LOCATION: GUIDANCE-STATE 
ACCURACY: N/A 


NAME TDLR-VELOCITY 
DESCRIPTION: Velocity as computed by 
the touch down landing radar 
USED IN: 2 4 CP, 2.7 GP, 2 9 TDLRSP 

UNITS: , 

RANGE: (-100, 100] 

DATA TYPE;array (1.3, 0..4) of real's 
ATTRIBUTE: data 

DATA STORE LOCATION: SENSOR-OUTPUT 
ACCURACY: TBD 


NAME: TDLRSP-DONE 
DESCRIPTION. Flag indicating 
completion of 2 9 TDLRSP task 
USED IN 2. RUN-GCS 
UNITS: none 

RANGE: [0: running of task 2 11 TDLRSP incomplete, 
1 running of task 2 10 TDSP complete] 

DATA TYPE: logical*! 

ATTRIBUTE: control 

DATA STORE LOCATION: none 

ACCURACY: N/A 


NAME: TDLRSP -SWITCH 
DESCRIPTION: Flag indicating 
whether or not the touch down landing 
radar sensor processor is turned on. 

USED IN: 1. INIT-GCS 
UNITS none 

RANGE: (0: processor is off, 

1 : processor is on .] 

DATA TYPE: logical* 1 
ATTRIBUTE data condition 
DATA STORE LOCATION: GUIDANCE 
ACCURACY N/A 


NAME TDSP -DONE 
DESCRIPTION: Flag indicating 
completion of 2.10 TDSP task 
USED IN: 2. RUN-GCS 
UNITS none 

RANGE [0: running of task 2 10 TDSP incomplete, 
1: running of task 2 10 TDSP complete] 

DATA TYPE logicaJ*l 
ATTRIBUTE: control 
DATA STORE LOCATION none 
ACCURACY: N/A 


NAME TDSP -SWITCH 
DESCRIPTION Flag indicating 
whether or not the touch down sensor 
is turned on 
USED IN: 0 GCS 
UNITS: none 

RANGE: [0 touch down sensor is off, 

1: touch down sensor is on.] 

DATA TYPE: logicaI*l 
ATTRIBUTE; data condition 
DATA STORE LOCATION GUIDANCE 
ACCURACY N/A 


NAME: TDS-STATUS 

DESCRIPTION status of the touch down sensor 
USED IN: 2 4 CP, 2.7 GP, 2.10 TDSP 
UNITS: none 

RANGE: [0 := healthy. 1 = failed] 

DATA TYPE logical‘1 
ATTRIBUTE: data 

DATA STORE LOCATION: GUIDANCE .STATE 
ACCURACY N/A 


NAME: TE-DROP 

DESCRIPTION: The axial thrust error when 
axial engines are warm and the velocity 
altitude contour has not been intersected 
USED IN: 2.1 AECLP 
UNITS none 
RANGE; [-2, 2] 

DATA TYPE real** 

ATTRIBUTE: data 

DATA STORE LOCATION: RUN -PARAMETERS 
ACCURACY: N/A 


NAME: TEJNIT 

DESCRIPTION: The axial thrust error 
when the axial engines are cold 
USED IN: 2.1 AECLP 
UNITS: none 
RANGE: [-2, 2] 

DATA TYPE: real** 

ATTRIBUTE, data 

DATA STORE LOCATION: RUN-PARAMETERS 
ACCURACY: N/A 


NAME: TEJNTEGRAL 

DESCRIPTION: Integral portion of Thrust 
error equation 

USED IN: 2.1 AECLP. 2.4 CP 
UNITS meters 
RANGE [-1000, 1000] 

DATA TYPE real** 

ATTRIBUTE data 

DATA STORE LOCATION GUIDANCE-STATE 
ACCURACY: TBD 


NAME: TE-LIM1T 

DESCRIPTION Limiting thrust error 
USED IN: 2 1 AECLP 
UNITS: none 
RANGE: (-10000, 10000] 

DATA TYPE: real** 

ATTRIBUTE Data 

DATA STORE LOCATION: GUIDANCE -STATE 
ACCURACY: TBD 
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NAME T E _M A X 

DESCRIPTION: Maximum thrust error permissible 
USED IN 2.1 AECLP 
UNITS: none 
RANGE. [-2, 2] 

DATA TYPE: real*8 
ATTRIBUTE data 

DATA STORE LOCATION: RUN -PARAMETERS 
ACCURACY: N/A 


NAME: T E _M IN 

DESCRIPTION Minimum thrust error tolerable 
USED IN. 2.1 AECLP 
UNITS: none 
RANGE ['2, 2] 

DATA TYPE: real*8 
ATTRIBUTE: data 

DATA STORE LOCATION: RUN _PARA METERS 
ACCURACY: N/A 


NAME: THERMO. TEMP 

DESCRIPTION thermocouple pair temperature 

USED IN; 2 11 TSP 

UN ITS: none 

RANGE: (0, 2 15 - lj 

DATA TYPE Integer*2 

ATTRIBUTE data 

DATA STORE LOCATION EXTERNAL 
ACCURACY N/A 


NAME THETA 

DESCRIPTION: initial pulse angle 
USED IN 2 8 RECLP 
UNITS: radians 
RANGE: [ — w, rr] 

DATA TYPE real*8 
ATTRIBUTE: data 

DATA STORE LOCATION: GUIDANCE 
ACCURACY: TBD 


NAME: THETA1 

DESCRIPTION pulse angle boundary 
USED IN: 2.8 RECLP 
UNITS: radians 
RANGE [0, 0 05} 

DATA TYPE real's 
ATTRIBUTE: data 

DATA STORE LOCATION: RUN_PA RAMETERS 
ACCURACY: N/A 


NAME THETA2 

DESCRIPTION: pulse angle boundary 
USED IN 2 8 RECLP 
UNITS: radians 
RANGE [0, 0 05] 

DATA TYPE real'8 
ATTRIBUTE: data 

DATA STORE LOCATION RUN _PA R AM ETERS 
ACCURACY N/A 


NAME TS .STATUS 

DESCRIPTION: status of the temperat ure sensors 
in solid state, then thermocouple pair order 
USED IN 2 4 CP, 2 11 TSP 
UNITS none 

RANGE: (0 = healthy, 1 = failed] 

DATA TYPE array (12) of logical'l 
ATTRIBUTE data 

DATA STORE LOCATION GUIDANCE-STATE 
ACCURACY: N/A 


NAME: TSP-DONE 
DESCRIPTION: Flag indicating 
completion of 2 11 TSP task 
USED IN: 2. RUN.GCS 
UNITS: none 

RANGE: (0: running of task 2 11 TSP incomplete, 
1 running of task 2 11 TSP complete) 

DATA TYPE: logical'l 
ATTRIBUTE control 
DATA STORE LOCATION: none 
ACCURACY: N/A 


NAME VELOCITY-ERROR 

DESCRIPTION; Distance from velocity-altitude 

contour. (Difference in velocities from actual 

to desired on contour 

USED IN 2.1 AECLP, 2 4 CP, 2.7 GP 

units: mclcra 

„ second 

RANGE: [-1500, 1500} 

DATA TYPE: real*# 

ATTRIBUTE: data 

DATA STORE LOCATION: GUIDANCE-STATE 
ACCURACY: TBD 


NAME: YEJNTEGRAL 
DESCRIPTION: Integral portion of Yaw 
error equation 

USED IN: 2 1 AECLP, 2.4 CP 
UNITS: meters 
RANGE [-1000, 1000J 
DATA TYPE: real*# 

ATTRIBUTE: data 

DATA STORE LOCATION: GUIDANCE -STATE 
ACCURACY; TBD 


NAME: YE-MAX 

DESCRIPTION: Maximum yaw error permissible 
USED IN 2 1 AECLP 
UNITS: none 
RANGE (-1, 1] 

DATA TYPE; real*# 

ATTRIBUTE: data 

DATA STORE LOCATION: RUN PARAMETERS 
ACCURACY: N/A 


NAME YE.MIN 

DESCRIPTION; Minimum yaw error tolerable 
USED IN; 2 1 AECLP 
UNITS: none 
RANGE: [-1, 1} 

DATA TYPE: real*# 

ATTRIBUTE data 

DATA STORE LOCATION: RUN PARAMETERS 
ACCURACY: N/A 
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PART II. CONTENTS OF DATA STORES 


Table 7.1: DATA STORE: GUIDANCE-STATE 


VARIABLE NAME 

USED BY: 

A.STATUS 

2.3 ASP, 2.4 CP “ 

AE.STATUS 

2.1 AECLP, 2.4 CP 

AE-SWITCH 

2.1 AECLP, 2.7 GP 

AE.TEMP 

2.1 AECLP, 2.4 CP, 2.5 CRCP, 2.7 GP 

AR.STATUS 

2.2 ARSP, 2.4 CP 

C.STATUS 

2.4 CP 

CHUTE-RELEASED 

2.1 AECLP, 2.4 CP, 2.5 CRCP, 2.7 GP 

CONTOUR-CROSSED 

2.1 AECLP, 2.4 CP, 2.7 GP 

FRAME_BEAM-UNLOCKED 

2.9 TDLRSP 

FRAME-ENGINESJGN1TED 

2.1 AECLP, 2.7 GP 

G.STATUS 

2.4 CP, 2.6 GSP 

GP-ALTITUDE 

2.4 CP, 2.7 GP, 2.1 AECLP 

GP-ATTITUDE 

2.4 CP, 2.7 GP 

GP.PHASE 

2.4 CP, 2.7 GP 

GP.ROTATION 

2.1 AECLP, 2.4 CP, 2.7 GP 

GP.VELOCITY 

2.1 AECLP, 2.4 CP, 2.7 GP 

INTERN AL-CMD 

2.1 AECLP 

K-ALT 

2.2 ARSP, 2.4 CP, 2.7 GP 

K.MATRIX 

2.4 CP, 2.7 GP, 2.9 TDLRSP 

PE-INTEGRAL 

2.1 AECLP, 2.4 CP 

RE-STATUS 

2.4 CP, 2.8 RECLP 

RE-SWITCH 

INIT-GCS, 2.7 GP, 2.8 RECLP 

TDLR-STATE 

2.4 CP, 2.7 GP, 2.9 TDLRSP 

TDLR-STATUS 

2.4 CP, 2.9 TDLRSP 

TDLRSP-S WITCH 

INIT-GCS 

TDS -STATUS 

2.4 CP, 2.7 GP, 2.10 TDSP 

TDSP-SWITCH 

0. GCS 

TEJNTEGRAL 

2.1 AECLP, 2.4 CP 

TE-LIMIT 

2.1 AECLP 

THETA 

2.8 RECLP 

TS.STATUS 

2.4 CP, 2.11 TSP 

VELOCITY.ERROR 

2.1 AECLP, 2.4 CP, 2.7 GP 

YEJNTEGRAL 

2.1 AECLP, 2.4 CP 
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Table 7.2: DATA STORE: EXTERNAL 


VARIABLE NAME 

USED BY 

A-COUNTER 

2.3 ASP 

AE-CMD 

2.1 AECLP, 2. 4 CP 

AR.COUNTER 

2.2 ARSP 

FRAME-COUNTER 

2.1 AECLP, 2.4 CP, 2.7 GP, 2.9 TDLRSP 

G.COUNTER 

2.6 GSP 

PACKET 

2.4 CP 

RE-CMD 

2.8 RECLP, 2.4 CP 

SS-TEMP 

2.11 TSP 

TD-COUNTER 

2.10 TDSP 

TDLR-COUNTER 

2.9 TDLRSP 

THERMO-TEMP 

2.11 TSP 


Table 7.3: DATA STORE: SENSOR-OUTPUT 


VARIABLE NAME 

USED BY: 

A -ACCELERATION 

AR.ALTITUDE 

ATMOSPHERIC-TEMP 

G.ROTATION 

TD.SENSED 

TDLR. VELOCITY 

2.1 AECLP, 2.3 ASP, 2.4 CP, 2.7 GP 

2.2 ARSP, 2.4 CP. 2.7 GP 

2.3 ASP, 2.4 CP, 2 6 GSP. 2.11 TSP 

2.4 CP, 2.6 GSP, 2.7 GP, 2.8 RECLP 
2.4 CP, 2.7 GP, 2.10 TDSP 

2.4 CP, 2.7 GP, 2.9 TDLRSP 
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Table 7.4: DATA STORE: RUN-PARAMETERS 


VARIABLE NAME 

USED BY 

A-BIAS 

2.3 ASP 

A-GAIN.O 

2.3 ASP 

A-SCALE 

2.3 ASP 

ALPHA-MATRIX 

2.3 ASP 

AR.FREQUENCY 

2.2 ARSP 

COMM-SYNC.PATTERN 

2.4 CP 

CONTOUR-ALTITUDE 

2.7 GP 

CONTOUR-VELOCITY 

2.7 GP 

DELTA-T 

2.7 GP, 2.8 RECLP, 2.9 TDLRSP 

DROP-HEIGHT 

2.7 GP 

ENGINES-ON-ALTITUDE 

2.1 AECLP, 2.7 GP 

FULL-UP-TIME 

2.1 AECLP 

G1 

2.3 ASP 

G2 

2.3 ASP 

G3 

2.6 GSP 

G4 

2.6 GSP 

G-GAIN-0 

2.6 GSP 

G.OFFSET 

2.6 GSP 

GA 

2.1 AECLP 

GAX 

2.1 AECLP 

GP1 

2.1 AECLP 

GP2 

2.1 AECLP 

GPY 

2.1 AECLP 

GQ 

2.1 AECLP 

GR 

2.1 AECLP 

GRAVITY 

2.7 GP 

GV 

2.1 AECLP 

GVE 

2.1 AECLP 

GVEI 

2.1 AECLP 

GVI 

2.1 AECLP 

GW 

2.1 AECLP 

GWI 

2.1 AECLP 

Ml 

2.11 TSP 

M2 

2.11 TSP 

M3 

2.11 TSP 

M4 

2.11 TSP 

OMEGA 

2.1 AECLP 
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Table 7.5: DATA STORE: RUN -PARAMETERS (cont.) 


VARIABLE NAME 

USED BY 

PI 

2.8 RECLP 

P2 

2.8 RECLP 

P3 

2 8 RECLP 

P4 

2.8 RECLP 

PE-MAX 

2.1 AECLP 

PE.MIN 

2 1 AECLP 

T1 

2.11 TSP 

T2 

2.11 TSP 

T3 

2.11 TSP 

T4 

2.11 TSP 

TDLR.ANGLES 

2.9 TDLRSP 

TDLR.GAIN 

2.9 TDLRSP 

TDLR-LOCK.TIME 

2.9 TDLRSP 

TDLR.OFFSET 

2.9 TDLRSP 

TE.DROP 

2.1 AECLP 

TEJNIT 

2.1 AECLP 

TE.MAX 

2.1 AECLP 

TE.MIN 

2.1 AECLP 

THETA 1 

2.8 RECLP 

THETA2 

2 8 RECLP 

YE-MAX 

2.1 AECLP 

YE-MIN 

2.1 AECLP 





PART III. LIST OF CONTROL VARIABLES 
AND DATA CONDITIONS 


Table 7.6 CONTROL VARIABLES (OPTIONAL USAGE) 


CONTROL VARIABLE NAME 

AECLP.DONE 

ARSP-DONE 

ASP-DONE 

CRCP.DONE 

GP.DONE 

GSP.DONE 

TDLRSP-DONE 

TDSP-DONE 

TSP.DONE 


Table 7.7 DATA CONDITIONS (REQUIRED USAGE) 


DATA CONDITION VARIABLE NAME 

AE.TEMP ~ 

CHUTE-RELEASED 

TD-SENSED 

TDLR.STATE 
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Table 7.8: INITIALIZATION DATA 


VARIABLE NAME 

USED BY 

ACCELERATION 

2.1 AECLP, 2.3 ASP, 2.4 CP, 2.7 GP 

A.BIAS 

2.3 ASP 

A-COUNTER 

2.3 ASP 

A-GAIN-0 

2.3 ASP 

A-SCALE 

2.3 ASP 

A STATUS 

2.3 ASP, 2.4 CP 

AE-STATUS 

2.1 AECLP, 2.4 CP 

AE-SWITCH 

2.1 AECLP, 2.7 GP 

AE.TEMP 

2.1 AECLP, 2.4 CP, 2.5 CRCP, 2.7 GP 

ALPHA-MATRIX 

2.3 ASP 

AR.ALTITUDE 

2.2 ARSP, 2.4 CP, 2.7 GP 

AR-COUNTER 

2.2 ARSP 

ARTREQUENCY 

2.2 ARSP 

AR-STATUS 

2.2 ARSP, 2.4 CP 

ATMOSPHERIC-TEMP 

2.3 ASP, 2.4 CP, 2.6 GSP, 2.11 TSP 

C.STATUS 

2.4 CP 

CHUTE-RELEASED 

2.1 AECLP, 2.4 CP, 2.5 CRCP, 2.7 GP 

COMM.SYNC-PATTERN 

2.4 CP 

CONTOUR-ALTITUDE 

2.7 GP 

CONTOUR-CROSSED 

2.1 AECLP, 2.4 CP, 2.7 GP 

CONTOUR-VELOCITY 

2.7 GP 

DELTA.T 

2.7 GP 

DROP-HEIGHT 

2.7 GP 

ENGINES-ON-ALTITUDE 

2.1 AECLP, 2.7 GP 

FRAME-BEAM-UNLOCKED 

2.9 TDLRSP 

FRAME-COUNTER 

2.1 AECLP, 2.4 CP, 2.7 GP, 2.9 TDLRSP 

FRAME-ENGINES -IGNITED 

2.1 AECLP, 2.7 GP 

FULL-UP-TIME 

| 2.1 AECLP 
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Table 7.9: INITIALIZATION DATA (cont.) 


VARIABLE NAME 

USED BY 

G1 

"2.3 ASP " 

G2 

2.3 ASP 

G3 

2.6 GSP 

G4 

2.6 GSP 

G.COUNTER 

2.6 GSP 

G-GAIN.O 

2.6 GSP 

G.OFFSET 

2.6 GSP 

G .ROTATION 

2.4 CP, 2.6 GSP, 2.7 GP, 2.8 RECLP 

G.STATUS 

2.4 CP, 2.6 GSP 

GA 

2.1 AECLP 

GAX 

2.1 AECLP 

GP1 

2.1 AECLP 

GP2 

2.1 AECLP 

GP-ALTITUDE 

2.7 GP, 2.1 AECLP 

GP-ATTITUDE 

2.7 GP 

GP.PHASE 

2.4 CP, 2.7 GP 

GP-ROTATION 

2.7 GP, 2.8 RECLP 

GP-VELOCITY 

2.7 GP 

GPY 

2.1 AECLP 

GQ 

2.1 AECLP 

GR 

2.1 AECLP 

GRAVITY 

2.7 GP 

GV 

2.1 AECLP 

GVE 

2.1 AECLP 

GVEI 

2.1 AECLP 

GVI 

2.1 AECLP 

GW 

2.1 AECLP 

GWI 

2.1 AECLP 
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Table 7.10: INITIALIZATION DATA (cont.) 


VARIABLE NAME 

USED BY 

K-ALT 

2.2 ARSP, 2.4 CP, 2.7 GP 1 

K.MATRIX 

2.4 CP, 2.7 GP, 2.9 TDLRSP 

Ml 

2.11 TSP 

M2 

2.11 TSP 

M3 

2.11 TSP 

M4 

2.11 TSP 

OMEGA 

2.1 AECLP 

PI 

2.8 RECLP 

P2 

2.8 RECLP 

P3 

2.8 RECLP 

P4 

2.8 RECLP 

PEJNTEGRAL 

2.1 AECLP, 2.4 CP 

PE-MAX 

2.1 AECLP 

PE.MIN 

2.1 AECLP 

RE-STATUS 

2.4 CP, 2.8 RECLP 

RE-SWITCH 

INIT.GCS, 2.7 GP, 2.8 RECLP 

SS.TEMP 

2.11 TSP 

T1 

2.11 TSP 

T2 

2.11 TSP 

T3 

2.11 TSP 

T4 

2.11 TSP 

TD.SENSED 

2.4 CP, 2.7 GP, 2.10 TDSP 

TDLR-ANGLES 

2.9 TDLRSP 

TDLR-COUNTER 

2.10 TDSP 

TDLR.GAIN 

2.9 TDLRSP 

TDLR-LOCK.TIME 

2.9 TDLRSP 

TDLR-OFFSET 

2.9 TDLRSP 

TDLR-STATE 

2.4 CP, 2.7 GP, 2.9 TDLRSP 

TDLR.STATUS 

2.4 CP, 2.9 TDLRSP 

TDLR.VELOCITY 

2.4 CP, 2.7 GP, 2.9 TDLRSP 



Table 7.11: INITIALIZATION DATA (cont.) 


VARIABLE NAME 

USED BY 

TDLRSPJSWITCH 

INIT.GCS 

TDS.STATUS 

2.4 CP, 2.7 GP, 2.10 TDSP 

TDSP-SWITCH 

0. GCS 

TE.DROP 

2.1 AECLP 

TEJNIT 

2.1 AECLP 

TE.INTEGRAL 

2.1 AECLP, 2.4 CP 

TE. LIMIT 

2.1 AECLP 

TE.MAX 

2.1 AECLP 

TE.MIN 

2.1 AECLP 

THERMO-TEMP 

2.11 TSP 

THETA 

2.8 RECLP 

THETA1 

2.8 RECLP 

THETA2 

2.8 RECLP 

TS .STATUS 

2.4 CP, 2.11 TSP 

VELOCITY-ERROR 

2.1 AECLP, 2.4 CP, 2.7 GP 

YE-INTEGRAL 

2.1 AECLP, 2.4 CP 

YE-MAX 

2.1 AECLP 

YE.MIN 

2.1 AECLP 
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A. FORMAT OF THIS SPECIFICATION 
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INTRODUCTION TO FORMAT 

This specification uses the extended structured analysis method advocated 
by Hatley [12, 13]. This method is based on a hierarchical approach to 
defining functional modules and the associated data and control flows. 

The documents constructed as a part of this specification include data 
context and flow diagrams; control context and flow diagrams; process, con- 
trol, and timing descriptions; and a requirements dictionary. Figure A.l 
defines the graphical symbols used in the data flow and control flow dia- 
grams respectively. 

The data flow diagrams describe the processes, data flows, data stores, 
and data conditions. The data context diagram is the highest-level data flow 
diagram and represents the data flow for the entire system. Data conditions 
are represented by directed arcs with broken lines. 

The control flow diagrams describe processes, control signal flows, and 
stores. The control signal flows are depicted using directed arcs with broken 
lines. The control signals listed in the data dictionary may be implemented 
by the programmer in any form desired, or they may be completely ignored 
and the control of the program conducted through other means. They simply 
show the logic involved in the system. Signal flows between the control 
flow diagram and the control specification have a short bar at the end of 
the directed arc. The control flow diagrams contain duplicate descriptions 
of the processes represented on the data flow diagram. This duplication 
of processes is consistent with the approach of slaving the control flow to 
the data flow. The control context diagram representing the most abstract 
control flow is similar to the data context diagram. 

The control specifications describe the control requirements of a system. 
These specifications contain the conditions when the processes detailed in 
the data and control flow diagrams are activated and de activated. 

The requirements dictionary contains definitions for both data and con- 
trol signals. 
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Figure A.l: GRAPHICAL SYMBOLS USED IN FLOW DIAGRAMS 
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B. IMPLEMENTATION NOTES 
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INTERFACE 


Background 

For the purposes of this research experiment, each GCS software implemen- 
tation must function as if it were actually controlling a planetary lander. In 
reality, each GCS implementation will be interacting with a software simula- 
tor (GCS _SIM) that models the behavior of a physical lander when exposed 
to the environmental forces of a planet. 

Due to the fact that each GCS implementation must interact with GCS-SIM 
as if it were connected to the lander hardware, there are some additional 
requirements that are placed on a GCS implementation that help define a 
software interface. The software interface to the simulator replaces the phys- 
ical connection to planetary lander hardware through the use of a simulator 
support utility and an additional requirement involving the organization of 
the global data stores. 

Simulator Support Utility 

A single simulator support utility (GCS-SIM JIENDEZVOUS) is provided 
to form a uniform interface between the GCS applications software and the 
simulation environment (GCS-SIM). This utility is a routine which simpli- 
fies the interface between the GCS implementations and the simulation of 
the vehicle sensing and control mechanisms. This utility also includes a syn- 
chronization mechanism for the configurations using more than one version 
of the GCS. This routine provides the following support functions: 

• Initialization for the Beginning of Terminal Descent 

• Simulator Rendezvous Synchronization 

• GCS Interface for Simulated Reads and Writes 

Global Data Store Organization 

Part III of the data dictionary of this specification contains descriptions of 
four required data stores. Each of these data stores is to be located in a 
separate, globally accessible data region. By dividing the global data stores 
into four separate regions, they can be compared to components that would 
be found on a hardware interface (See Figure B.l). 
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Figure B.l: DIAGRAM OF STORAGE AS SEEN BY GCS IMPLEMEN- 
TATIONS 
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In FORTRAN, this would mean four common blocks with the labels as 
given in the header for each data store listing. There are ways of accomplish* 
ing this same type of data region in other languages, but they are outside 
the scope of this experiment. 

Input/Output 

The GCS_SIM_RENDEZVOUS routine simulates all of the input/output op- 
erations for each GCS implementation. When using the rendezvous routine 
with a GCS implementation, all data needed by rendezvous is passed via 
the four global data stores and there are no additional parameters required. 
AH information read from or written to each GCS application will be trans- 
ferred through the four global data stores defined in the data dictionary. 
The programmer should note that although normally some type of range 
checking/limiting would be included in control programs, there are some 
restrictions being placed by this experiment. The programmer is allowed 
to check values of variables to see if they are within the ranges specified 
in the data dictionary, but if values are outside the specified range, NO 
CHANGES should be made to them. For purposes of this experiment, 
the calculated values need to be passed to the simulator. Values returned 
from the simulator will always be within the specified range, so if the ap- 
plication sends out-of-range values to the simulator, these values will be 
put into range before being passed from the simulator to the next subframe 
processes. This means that all inputs to subframes may be assumed to be 
within the specified ranges. 

Process 

The GCS reads the sensor input values and processes them into control com- 
mands which are averaged by GCS.SIM and written to the control surfaces. 
Since GCS.SIM handles the orbit to terminal descent portion of each tra- 
jectory, a rendezvous must be issued at the start of each trajectory to load 
initial sensor values into each GCS application. Following the first call to 
rendezvous (time step equal to zero), all GCS applications will synchronize 
themselves by calling rendezvous at the end of each sub-frame. This ren- 
dezvous, in effect, suspends the GCS implementations until the other GCS 
implementations have processed this time step or have run out of time. 

The calling convention for this GCS J5IM provided support utility is as 
follows: 
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• GCS-SIM.RENDEZVOUS (requires no parameters) 


GCS Initialization 

During the initialization phase of each GCS trajectory - the first call to 
rendezvous - the frame counter value will be updated with the starting 
frame for the particular trajectory. Under normal circumstances, the value 
of the frame counter will be “1,” but do not rely on that. As errors occur 
in the GCS, they will be fixed; the trajectory may start at the beginning of 
the last complete frame that was processed without error. 


Local Variables 

In an attempt to accommodate everyone, most of the variables needed to 
manipulate functions within the GCS have been included in the data stores, 
which can be found in the data dictionary. Since a GCS can be started at 
the beginning of any frame, the programmer is responsible for establishing 
acceptable initialization values for any local variables (any variable not listed 
in the data dictionary) which may have been declared. Assume that some 
of the GCS-SIM may initialize the GCS with a list of variables from some 
saveset of previous global data store values. 

By using the interface described above, the simulator can be transparent 

to the implementation. 
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C. NUMERICAL INTEGRATION 
INSTRUCTIONS 
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Three locations exist within the GCS specification requiring the use of a 
highly accurate numerical integration method 1 . These locations are the 
calculations of GP.VELOCITY, GP-ALTITUDE, and GP -ATTITUDE in 
the Guidance Processor. To maintain the necessary degree of accuracy in 
certain output variables, three methods of numerical integration have been 
designated as acceptable for coding: Adams-Moulton method, Hamming’s 
method, and the Runge-Kutta fourth-order method. 

Each method is briefly described in the following paragraphs and refer- 
ences to numerical analysis texts describing the method are provided. Algo- 
rithms specified in either a text listed or another suitable numerical analysis 
text should be used during coding. 

Adams-Moulton Method requires values from the previous four time 
steps to calculate the value at the next time step. The Adams-Moulton 
method is a predictor/corrector method. Both [14] (pp. 346-7) and [16] 
(pp. 478-81) explain the Adams-Moulton method. 

Hamming s Method uses a predictor/corrector method similar to that 
of Adams-Moulton. Hamming’s method uses the same predictor as 
Milne’s, but uses a much simpler corrector formula. Milne’s method 
of integration was deemed to unstable for use, but Hamming’s method 
with the simpler corrector is sufficiently stable. A description of both 
Hamming’s method and Milne’s method can be found in [14] (pp 347- 
8 ). 

Runge-Kutta Fourth-Order Method The well-known Runge-Kutta fourth- 
order method requires only the previous two values to calculate the 
next value. References can be found in many texts including; [14] 

(pp. 352-8), [15] (pp. 273-80), [16] (pp. 481-6), and [17] (pp. 152-4). 


1 Note: not all integration required by the GCS specification requires the use of one 
of the methods listed in this appendix. More specifically, in computing TEJNTEGRAL 
PE-INTEGRAL, and YEJNTEGRAL, Euler’s method provides sufficient accuracy and 
simplicity and should be used. Information on Euler’s method mav be found in- fl4| 
(pp. 318 - 22 ), [ 15 ] (pg. 223 ), and [ 16 ] (pp. 462 - 3 ). 
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During the first time step, using a numerical integration method neces- 
sitates some specification of previous values. These values will be provided 
during initialization for the data elements provided in Table C.l. 

Table C.l: INITIAL VALUES PROVIDED FOR USE IN INTEGRATION 


A .ACCELERATION (1..3, 0..4) 
AR-ALTITUDE (0..4) 
GPJVLTITUDE (0..4) 
GP.ATTITUDE (1..3, 1. 3, 0..4) 
GP-VELOCITY (1..3, 0..4) 

G -ROTATION (1..3,0..4) 
K-ALT (0..4) 

K .MATRIX (1..3, 1..3, 0..4) 
TDLR-VELOCITY (1-3, 0.'i4)~ 


To insure that the numerical integration scheme coded provides sufficient 
accuracy in the output variable, an Accuracy Validation Utility Program 
(AVUP) will be used during acceptance testing. 
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